Allow Taffy to be used with f64 values where we currently f32

[nicoburns]

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.

https://github.com/linebender/xilem/issues/37#issuecomment-1387282971

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)

[alice-i-cecile]

I'm nervous about swapping completely: doubling the memory usage does matter, both in games and on mobile.

[nicoburns]

A couple of notes on this one:

• One option could be to use f64 for computation but still store f32. We'd need to benchmark, but I'd guess at f32 -> f64 conversion being cheap enough for this to be viable. If we turn Style into a trait then implementors of the API could choose how much precision they wish to store.
• It's going to be hard to implement #225 without expanding dimension to fit 64 bit values. As calc() requires very large values which must therefore be boxed or similar likely requiring a usize sized value. We could potentially work around this by using a truncated index into a Vec/SlotMap or similar. But SlotMap doesn't currently support smaller keys either (https://github.com/orlp/slotmap/issues/52) so we might need to implement our own storage. Also, if we use an index we'll need to carefully manage the lifecycle of the calc expressions, as it would be easy to leak them.

[nicoburns]

https://github.com/servo/servo/issues/29819

[Loara]

Instead to force f32 or f64 values I prefer to allow user to choose any "vector type" T that satisfies the following operations:

• lossless addition between two T types;
• lossy scalar multiplication between a T type and a scalar T::Scalar type (by default f64).

In this way you can use Layout also for TUI where dimensions must be integers or for "3D widgets" where instead dimensions are three-dimensional vectors.

[test3211234]

@Loara What is a 3D widget in TUI? I've never heard of that.