3 ms·

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

Gecko is base-60 a.k.a. sexagesimal (https://en.wikipedia.org/wiki/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 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/d36cf98aa85f24ceefd07521b3d16b9edd2abcb7/gfx/src/nsCoord.h https://github.com/mozilla/gecko-dev/blob/d36cf98aa85f24ceef... and https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/geometry/layout_unit.h https://source.chromium.org/chromium/chromium/src/+/main:thi...

Karellen 4y ago
> 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/e632c1393ebedfdab10ec1ced8324a48252b8aa5 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.

Karellen 4y ago

> 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/e632c1393ebedfdab10ec1ced8324a48252b8aa5 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.