What problem does this solve or what need does it fill?
I haven't had a chance to review in detail, but I can answer the f64 question. For a very large scrolling area, the scroll offset would lose precision (ie not even be able to represent an integer scroll offset) around 2^24. On CPU, the speed of doing f64 arithmetic is generally the same as f32.
linebender/xilem#37 (comment)
2^24 is 16,777,216 which seems very high. But I suppose that's not out of the range of a very long scroll region, and of course we also need to be able to represent decimal values.
What solution would you like?
Either:
- Taffy should be made generic over the float type (allowing either f32 or f64 to be picked by the caller)
- Or Taffy should just switch from f32 to f64
What alternative(s) have you considered?
Accept that Taffy won't work precisely at large sizes.
Additional context
We might want to think about how this interacts with #225 (which may want to add a pointer or slotmap key value to Dimension)
What problem does this solve or what need does it fill?
linebender/xilem#37 (comment)
2^24 is 16,777,216 which seems very high. But I suppose that's not out of the range of a very long scroll region, and of course we also need to be able to represent decimal values.
What solution would you like?
Either:
What alternative(s) have you considered?
Accept that Taffy won't work precisely at large sizes.
Additional context
We might want to think about how this interacts with #225 (which may want to add a pointer or slotmap key value to Dimension)