taffy
taffy copied to clipboard
DioxusLabs
Taffy points actually seem to represent pixel sizes
@alice-i-cecile I believe that (contrary to the documentation),
Pointsin taffy actually are pixels. I've been meaning to open an issue suggesting we rename the variant. Although I suppose, given that we only have one absolute unit, it could actually represent anything and it wouldn't make any difference. But for example, our generated tests use pixel values when running in chrome and Points in taffy.
Originally posted by @nicoburns in https://github.com/DioxusLabs/taffy/pull/232#discussion_r993598492
This is also how they're used upstream in Bevy.
I think it's better for Taffy to stay on something abstract like Points instead of something specific like Pixels. It's up to the user to decide what they will use
@geom3trik Essentially Taffy just has one unit, along with percentages. As such, what that unit corresponds to is really up to the caller of the library who can use it to represent whatever they like.
@mockersf I'm somewhat sympathetic to that point of view, however Taffy's Points are currently documented to be the typographical notion of points (where 1 point = 1/72 of an inch), not an abstract notion of points. At the very least I think that documentation ought be updated. However, CSS also uses "points" in this sense so I wonder whether that might get confusing, and pixels might be less ambiguous even if they don't correspond 1:1 with screen pixels.
I wonder whether that might get confusing, and pixels might be less ambiguous even if they don't correspond 1:1 with screen pixels.
For morphorm I used the pixels name but they actually represent logical points which are then scaled by DPI before being passed to the layout system. However, I'm considering changing it to points because now I'm wondering if both should exist. Points for when you want the logical pixels, and pixels for when you want physical pixels no matter the DPI. I don't know if this is a good idea or not but I noticed on a laptop I have with a 1.25 scale factor that things looked bad because often multiplying by that scale factor still results in fractional values. The other option is to always round to the nearest physical pixel but I'm not sure if that's the right solution or not. Hence the idea to provide points and pixels.
For morphorm I used the pixels name but they actually represent logical points which are then scaled by DPI before being passed to the layout system. I don't know if this is a good idea or not but I noticed on a laptop I have with a 1.25 scale factor that things looked bad because often multiplying by that scale factor still results in fractional values.
Could you fix this by scaling before running through the layout computation (morphorm/taffy)?
The other option is to always round to the nearest physical pixel but I'm not sure if that's the right solution or not.
I'm not sure if you currently do rounding on the logical pixels, but that's what Taffy does. It computes everything, and then the final step is a rounding pass.
Could you fix this by scaling before running through the layout computation (morphorm/taffy)?
That's what I'm doing currently, but 1.25 is an awkward scale factor. Let's say you have 5px of space between elements, now it becomes 6.25 and you end up with some blurry edges from the AA. The more I think about it the more I think it probably should be rounded.
I'm not sure if you currently do rounding on the logical pixels, but that's what Taffy does. It computes everything, and then the final step is a rounding pass.
So there is some rounding already, but just for stretch/flexible space and size and for percentages. I didn't think pixels needed to be rounded because at the time I wrote it pixels meant pixels and not points. I think this distinction is important, so circling back to the original point of this issue, I think it should be kept as points in taffy (and morphorm should probably follow this).
This does raise a question though, should the user be able to specify a dimension in actual pixels?