4 ms·

Doing lot's of WebGL, I'm still surprised we don't have a way to describe things in native screen pixels, but rely on a mix of dpr [1] and using 4 corners of a

Doing lot's of WebGL, I'm still surprised we don't have a way to describe things in native screen pixels, but rely on a mix of dpr [1] and using 4 corners of a DOM object [2] to calculate true size in relation to CSS pixels. Works great across all platforms, but still doesn't give true pixels in certain combinations of screen DPI and resolution. I understand why web has to be this way, but it still baffles me that such a basic thing is so hard. [1] https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio https://developer.mozilla.org/en-US/docs/Web/API/Window/devi... [2] https://stackoverflow.com/a/35244519 https://stackoverflow.com/a/35244519

paulddraper 1y ago
I don't really understand your point. This is common among visual technologies. There are logical pixels, an abstract description of size. And there are physical pixels, that are the actual dots of color. --- This is not unlike a printed page of text. The font size is measured in points. The physical output is dots and determined by DPI.
- 01HNNWZ0MV43FF 1y ago
  Yeah but when I'm making a game it would be nice to render exactly the right amount of pixels for a desktop display I targeted Firefox and ended up with some bonkers magic constant where a pixel was actually like 1.05 pixels or something. If I don't render enough it'll be blurry. If I render too many it's wasteful. If I am slightly off then the filtering will make it look weird It's not a phone with a Bayer matrix, it's not VR, I don't know why they have to be weird about it
  - SAI_Peregrinus 1y ago
    If I play your pixel-exact game on my 21" diagonal 3840x2160 pixel monitor, does it show up as 1/4 the size from when I play it on my 21" diagonal 1920x1080 monitor?
    - FrostKiwi 1y ago
      That of course depends on the implementation. The point is not the game or the UI ignoring DPI scaling or browser zoom, in fact you would want to support that. The point is, that you cannot do so on a pixel perfect-level across the board, because the widely supported way to do so, DevicePixelRatio, is just that: a ratio with precision issues under certain combinations of screen dpi and browser zoom. The browser can do pixel perfect rendering, it has to for sharp text. But in WebGL there is no reliable way to get the coordinates to do so as well. Browser specific ways to do so exist, but using standard APIs doesn't work browser zooms like 130% or DPI scales like 1.25 in combination with certain resolutions.
  - paulddraper 1y ago
    To be honest, a lot of what you're saying doesn't make sense. But yes you can have "bonkers" devicePixelRatio. Namely, when the browser is zoomed. Logical pixels measure UI "size." And Physical pixels (logical pixels * devicePixelRatio) is the number of dots. Your game layout should target logical pixels. And rasterization, textures, etc should target physical pixels. If weird devicePixelRatio causes problems with a lot of pixel-exact UI, you may choose to use your own logical pixels that has a rounded devicePixelRatio. --- I have a MacBook with a retina display. Versus a non-retina display, I would not expect that everything is 2x smaller, but rather 2x more detailed (or, if not that, the same level of detail but same size). That important distinction is reason for two different constants.
    - FrostKiwi 1y ago
      > If weird devicePixelRatio causes problems with a lot of pixel-exact UI, you may choose to use your own logical pixels that has a rounded devicePixelRatio. Exactly that is unfortunately not possible, you may or may not get off by one resolution. > I would not expect that everything is 2x smaller Of course. > but rather 2x more detailed That's specifically the thing you cannot guarantee, as sometimes due to lack of standarization, it maybe 2.01x size, leading to those UI elements being the right size, but slightly blurry due to pixel grid mismatches.
- FrostKiwi 1y ago
  Very much unlike printed text, for 3D and 2D rendering, the difference between native and non native resolutions is huge in terms of sharpness. A whole host of rendering techniques give subpar results if that cannot be guaranteed, even if off by one pixel. It's a basic necessity, that in WebGL you may or may not have.
o11c 1y ago
Use an img srcset and inspect currentSrc?
- bawolff 1y ago
  window.devicePixelRatio ?
  - o11c 1y ago
    Parent said that's not reliable apparently.
  - FrostKiwi 1y ago
    DevicePixelRatio changes with screen DPI and browser zoom, some combinations result in repeating decimals. You will get off by one pixel rendering and thus a sudden loss in sharpness due to the whole canvas getting bilinear interpolation.
jdashg 1y ago
Well unfortunately, the device pixel size of something does actually depend not just on the css size and dpr scaling, but also on position and iirc even potentially what else is on the page due to think like border and thin line dilation. Unfortunately that's just how css layout works in practice, due to pixel snapping and dealing with ambiguities in how to render thin or generally non-integer-sized elements. There are two approaches these days though: https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/WebGL_best_practices#devicepixelratio_and_high-dpi_rendering https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/W...
- FrostKiwi 1y ago
  > There are two approaches these days I'm aware of those, it's just sad nothing is nailed as a standard. Those are two workarounds unfortunately. A browser API not supported on Apple Safari and pixel-presnap with JS doing the CSS px calculation backwards + snapping and even that code has an extra branch to fix a macOS+Chrome bug. The whole situation smells of duct tape.

paulddraper 1y ago

I don't really understand your point. This is common among visual technologies. There are logical pixels, an abstract description of size. And there are physical pixels, that are the actual dots of color. --- This is not unlike a printed page of text. The font size is measured in points. The physical output is dots and determined by DPI.

01HNNWZ0MV43FF 1y ago
Yeah but when I'm making a game it would be nice to render exactly the right amount of pixels for a desktop display I targeted Firefox and ended up with some bonkers magic constant where a pixel was actually like 1.05 pixels or something. If I don't render enough it'll be blurry. If I render too many it's wasteful. If I am slightly off then the filtering will make it look weird It's not a phone with a Bayer matrix, it's not VR, I don't know why they have to be weird about it
- SAI_Peregrinus 1y ago
  If I play your pixel-exact game on my 21" diagonal 3840x2160 pixel monitor, does it show up as 1/4 the size from when I play it on my 21" diagonal 1920x1080 monitor?
  - FrostKiwi 1y ago
    That of course depends on the implementation. The point is not the game or the UI ignoring DPI scaling or browser zoom, in fact you would want to support that. The point is, that you cannot do so on a pixel perfect-level across the board, because the widely supported way to do so, DevicePixelRatio, is just that: a ratio with precision issues under certain combinations of screen dpi and browser zoom. The browser can do pixel perfect rendering, it has to for sharp text. But in WebGL there is no reliable way to get the coordinates to do so as well. Browser specific ways to do so exist, but using standard APIs doesn't work browser zooms like 130% or DPI scales like 1.25 in combination with certain resolutions.
- paulddraper 1y ago
  To be honest, a lot of what you're saying doesn't make sense. But yes you can have "bonkers" devicePixelRatio. Namely, when the browser is zoomed. Logical pixels measure UI "size." And Physical pixels (logical pixels * devicePixelRatio) is the number of dots. Your game layout should target logical pixels. And rasterization, textures, etc should target physical pixels. If weird devicePixelRatio causes problems with a lot of pixel-exact UI, you may choose to use your own logical pixels that has a rounded devicePixelRatio. --- I have a MacBook with a retina display. Versus a non-retina display, I would not expect that everything is 2x smaller, but rather 2x more detailed (or, if not that, the same level of detail but same size). That important distinction is reason for two different constants.
  - FrostKiwi 1y ago
    > If weird devicePixelRatio causes problems with a lot of pixel-exact UI, you may choose to use your own logical pixels that has a rounded devicePixelRatio. Exactly that is unfortunately not possible, you may or may not get off by one resolution. > I would not expect that everything is 2x smaller Of course. > but rather 2x more detailed That's specifically the thing you cannot guarantee, as sometimes due to lack of standarization, it maybe 2.01x size, leading to those UI elements being the right size, but slightly blurry due to pixel grid mismatches.
FrostKiwi 1y ago
Very much unlike printed text, for 3D and 2D rendering, the difference between native and non native resolutions is huge in terms of sharpness. A whole host of rendering techniques give subpar results if that cannot be guaranteed, even if off by one pixel. It's a basic necessity, that in WebGL you may or may not have.

o11c 1y ago

Use an img srcset and inspect currentSrc?

bawolff 1y ago
window.devicePixelRatio ?
- o11c 1y ago
  Parent said that's not reliable apparently.
- FrostKiwi 1y ago
  DevicePixelRatio changes with screen DPI and browser zoom, some combinations result in repeating decimals. You will get off by one pixel rendering and thus a sudden loss in sharpness due to the whole canvas getting bilinear interpolation.

jdashg 1y ago

Well unfortunately, the device pixel size of something does actually depend not just on the css size and dpr scaling, but also on position and iirc even potentially what else is on the page due to think like border and thin line dilation. Unfortunately that's just how css layout works in practice, due to pixel snapping and dealing with ambiguities in how to render thin or generally non-integer-sized elements. There are two approaches these days though: https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/WebGL_best_practices#devicepixelratio_and_high-dpi_rendering https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/W...

FrostKiwi 1y ago
> There are two approaches these days I'm aware of those, it's just sad nothing is nailed as a standard. Those are two workarounds unfortunately. A browser API not supported on Apple Safari and pixel-presnap with JS doing the CSS px calculation backwards + snapping and even that code has an extra branch to fix a macOS+Chrome bug. The whole situation smells of duct tape.