Comment by progers7 | Hacker News Reader

Comment by progers7 | Hacker News Reader

Gecko is base-60 a.k.a. sexagesimal (https://en.wikipedia.org/wiki/Sexagesimal) which is highly divisible. In Firefox, a pixel is sort of a CSS minute :)

Blink and WebKit are less sexy and use tetrasexagesimal a.k.a. 1/64 (https://trac.webkit.org/wiki/LayoutUnit). 1/60 was tried originally, but it was switched to 1/64 for performance and to avoid precision loss. The reason it's faster is interesting: floating point values are also stored as number with a base-2 exponent, so to convert to/from floats, you can use shifts instead of needing division. The differences between 1/60 and 1/64 were important 10 years ago but are pretty minor now.

If you're interested, the code is at https://github.com/mozilla/gecko-dev/blob/d36cf98aa85f24ceef... and https://source.chromium.org/chromium/chromium/src/+/main:thi...

> Gecko is base-60 a.k.a. sexagesimal

Thanks for that. I was very confused as to why the value was about 7% larger than 16,777,216 (2²⁴), and not exactly that.

But assuming a binary representation (!) having the subdivisions be slightly fewer than a power of 2 (60 being slighly less than 64) means that the whole number limit will be slightly over a power of two, meaning that 60 × 17,895,697 should be a power of 2 (give or take a bit of rounding).

And if you do the multiplication, it's 1,073,741,820, which is... huh. 2³⁰ (- 4).

Why not 2³¹ or 2³²? Looks like they could at least double the CSS length limit there, even while continuing to allow negative lengths.

Edit: As we can see from the parent-linked source on line 36, there is:

    #  define nscoord_MAX nscoord((1 << 30) - 1)

which confirms the limit, but doesn't say why 30 is used instead of 31.

Edit2: Info in the commit message at https://github.com/mozilla/gecko-dev/commit/e632c1393ebedfda...

    nscoord_MAX is (1<<30) so that we can check for overflow *after* adding two nscoords.

Makes sense.

Reply on news.ycombinator.com