Lots of things get weird in edge cases with SVGs. E.g., one thing that keeps biting me is that Firefox always snaps x="X" y="Y" coordinates on <use> elements to the nearest CSS pixel (even if the pixel size is very large), but allows transform="translate(X,Y)" to keep its full subpixel precision. I've taken to double-checking all my SVGs at 3000% zoom just to spot all the seams that implementations can create.
As in n+1 == n once you go past 2^24 on a float and here they are at 2^25-1. So it doesn't quite make sense as a reason to me.
There's a post above that browsers divide pixels into 1/64th of a unit which accounts for 6bits which puts this limit at precisely that of a signed 32bit integer. This makes much much more sense than the significand of a float.
The correct answer. In particular, up to 2 ^ 24 the float32 behaves like a regular integer, which can be important in some cases. Above that value, the integer starts to have missing values, and strange int behavior such as (n+1)+1 not equal to (n+2)
But why are 32b floats relevant? JS, the language famously representing ints as floats, uses 64b floats. Who puts ints into 32b floats and cares about precision loss?
chrismorgan|6 months ago
Now SVG… try defining a view box up where float precision drops, and interesting things happen.
LegionMammal978|6 months ago
AnotherGoodName|6 months ago
As in n+1 == n once you go past 2^24 on a float and here they are at 2^25-1. So it doesn't quite make sense as a reason to me.
There's a post above that browsers divide pixels into 1/64th of a unit which accounts for 6bits which puts this limit at precisely that of a signed 32bit integer. This makes much much more sense than the significand of a float.
chriseing|6 months ago
yosefk|6 months ago