5 ms·

Is the almost-24-bit limit related to the fact that 32-bit floats have 24 bits of significand? (cf. https://en.wikipedia.org/wiki/Single-precision_floating-poin

Is the almost-24-bit limit related to the fact that 32-bit floats have 24 bits of significand? (cf. https://en.wikipedia.org/wiki/Single-precision_floating-point_format?wprov=sfti1#IEEE_754_standard:_binary32 https://en.wikipedia.org/wiki/Single-precision_floating-poin...)

chriseing 1y ago
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)
- yosefk 1y ago
  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?
  - matthewmacleod 1y ago
    Layout engines are not implemented in Javascript.
  - bobmcnamara 1y ago
    Plenty of embedded GPUs do coordinates that way. But I doubt they're running browsers.
  - chriseing 1y ago
    I didn't say JavaScript anywhere in my comment. No relation to JavaScript. Rendering is typically done in tiles, in GPU, and the best precision that can be used across all GPUs is float32. Some GPUs don't implement float64.
AnotherGoodName 1y ago
But it's specifically 25bits not 24? 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.
chrismorgan 1y ago
No. Everyone has always used fixed-point numbers for layout, see my comment for further details. Now SVG… try defining a view box up where float precision drops, and interesting things happen.
- LegionMammal978 1y ago
  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.

chriseing 1y ago

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)

yosefk 1y ago
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?
- matthewmacleod 1y ago
  Layout engines are not implemented in Javascript.
- bobmcnamara 1y ago
  Plenty of embedded GPUs do coordinates that way. But I doubt they're running browsers.
- chriseing 1y ago
  I didn't say JavaScript anywhere in my comment. No relation to JavaScript. Rendering is typically done in tiles, in GPU, and the best precision that can be used across all GPUs is float32. Some GPUs don't implement float64.

AnotherGoodName 1y ago

But it's specifically 25bits not 24? 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.

chrismorgan 1y ago

No. Everyone has always used fixed-point numbers for layout, see my comment for further details. Now SVG… try defining a view box up where float precision drops, and interesting things happen.

LegionMammal978 1y ago
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.