2 ms·

Browsers do wrong a lot of things. Some time ago I hacked this little test: https://datenwolf.net/rndrchk/ https://datenwolf.net/rndrchk/ EDIT: If everything

Browsers do wrong a lot of things. Some time ago I hacked this little test: https://datenwolf.net/rndrchk/ https://datenwolf.net/rndrchk/ EDIT: If everything is done correctly, the text in the upper div will remain unreadable. If browsers were doing gamma correct scaling, the perceived brightness of the checker pattern would not change. Even more problematic, when zooming the interpolation and blending also don't happen gamma correct. If mere nearest neighbor interpolation were applied, this would remain hidden. This becomes really annoying on HiDPI screens. For some reason the "px" CSS unit has been "redefined" as an "average-ish" angular distance when viewed on a 96DPI screen at an arm's length or so. And for higher resolutions px is scaled accordingly. Whoever came up with that nonsense created a lot of issues down the road. sigh EDIT: Also Opera (before it switched to WebKit) did some really funky business at the edges, when upscaling images. Interpolation would always clamp-to-edge instead of respecting the tiling mode.

zamadatix 8y ago
Regardless if they had included the device relative px in the spec or not CSS doesn't define rendering, it defines layout. I.e. it's intentional CSS doesn't allow you to define things in terms of physical device pixels. Technically you could hack it for real world devices with ton of media queries but that's not their intended usage (hence needing a ton). If you're intending to render something in the browser (calculating DOM elements, canvas, or anything else) they expect you to handle it in your rendering code (JS/WASM).
- datenwolf 8y ago
  The whole intention of my little test hack in the first place was to show, that without being able to define layout with device native unit precision, the end result becomes unpredictable. The idea was to apply a checkerboard background image to to body and div, but translate the checkerboard by 1px in the div. By their very nature pixel based images are defined in pixels. And the most naive way to display images is by a 1:1 mapping of image pixels to CSS px units. This is how things started out, and only later features like page zooming, responsive scaling, HiDPI and so on came to be. Of course that means that images must be scaled. But this scaling must be well defined, so that the output will only differ in resolution, but not layout or visual outcome after scaling. And right now browsers fail to do this. Two years ago, when I wrote came up with that test Opera and Android WebView did even fail to properly translate the position of the div background; it looked like if somewhere in the scaling at some point the translation was coerced into the device native units grid. A checkerboard pattern can be understood as a Haar wavelet; or in terms of spatial frequency space as ΣₖΣₗsin(x-k)/(x-k)·sin(x-l+π)/(x-l+π) When applied to the pixel sampling grid a 2×2 checkerboard pattern is right at the Nyquist limit. Upscaling it with an ideal filtering kernel (sin(x)/x = sinc(x) = Lanczos) yields a single frequency (sinusoid). Adding two such signals at exactly π phase difference gives perfect destructive interference. Add some phase difference and it becomes constructive. This little detour into signal theory should make it clear, that you have to take great care when scaling and positioning stuff in a layout. Scale corresponds to frequency, position corresponds to phase. And it should be noted, that in a visual signal, phase carries the bulk of information, hence image transformations should preserve the phase, where possible. That it also shows, that interpolation and blending is broken, too (i.e. doesn't respect gamma) is a secondary outcome.
  - zamadatix 8y ago
    If by "only later" you mean the original CSS1 spec in '96 then yeah. The web has been relative long enough that anyone who has ever hit "print" didn't have to worry about images being 1/6th the size of the rest of the page. I don't see how broken interpolation/blending is a secondary outcome. That it works only at "native" resolution is a result of interpolation being broken not the other way around. If it was fixed you wouldn't be looking to use device pixels (again except for something like canvas rendering of a web image editor).

zamadatix 8y ago

Regardless if they had included the device relative px in the spec or not CSS doesn't define rendering, it defines layout. I.e. it's intentional CSS doesn't allow you to define things in terms of physical device pixels. Technically you could hack it for real world devices with ton of media queries but that's not their intended usage (hence needing a ton). If you're intending to render something in the browser (calculating DOM elements, canvas, or anything else) they expect you to handle it in your rendering code (JS/WASM).

datenwolf 8y ago
The whole intention of my little test hack in the first place was to show, that without being able to define layout with device native unit precision, the end result becomes unpredictable. The idea was to apply a checkerboard background image to to body and div, but translate the checkerboard by 1px in the div. By their very nature pixel based images are defined in pixels. And the most naive way to display images is by a 1:1 mapping of image pixels to CSS px units. This is how things started out, and only later features like page zooming, responsive scaling, HiDPI and so on came to be. Of course that means that images must be scaled. But this scaling must be well defined, so that the output will only differ in resolution, but not layout or visual outcome after scaling. And right now browsers fail to do this. Two years ago, when I wrote came up with that test Opera and Android WebView did even fail to properly translate the position of the div background; it looked like if somewhere in the scaling at some point the translation was coerced into the device native units grid. A checkerboard pattern can be understood as a Haar wavelet; or in terms of spatial frequency space as ΣₖΣₗsin(x-k)/(x-k)·sin(x-l+π)/(x-l+π) When applied to the pixel sampling grid a 2×2 checkerboard pattern is right at the Nyquist limit. Upscaling it with an ideal filtering kernel (sin(x)/x = sinc(x) = Lanczos) yields a single frequency (sinusoid). Adding two such signals at exactly π phase difference gives perfect destructive interference. Add some phase difference and it becomes constructive. This little detour into signal theory should make it clear, that you have to take great care when scaling and positioning stuff in a layout. Scale corresponds to frequency, position corresponds to phase. And it should be noted, that in a visual signal, phase carries the bulk of information, hence image transformations should preserve the phase, where possible. That it also shows, that interpolation and blending is broken, too (i.e. doesn't respect gamma) is a secondary outcome.
- zamadatix 8y ago
  If by "only later" you mean the original CSS1 spec in '96 then yeah. The web has been relative long enough that anyone who has ever hit "print" didn't have to worry about images being 1/6th the size of the rest of the page. I don't see how broken interpolation/blending is a secondary outcome. That it works only at "native" resolution is a result of interpolation being broken not the other way around. If it was fixed you wouldn't be looking to use device pixels (again except for something like canvas rendering of a web image editor).