Hacker News Reader

Comment by omeze | Hacker News Reader

I don't quite understand this (not a graphics dev) -- if you have the ability to get the viewport size in a browser, and if the display is running at its native resolution, why do you not have pixel-perfect accuracy?

View on HN

It depends on what the various different layers in between you and the gfx hardware are doing.

For instance, see the discussion on this "monitor calibration" shader: https://www.shadertoy.com/view/NsS3Rw

In that case, FireFox does not 100% provide some of the needed APIs in order to get pixel-perfect rendering. There's nothing you can do to fix that yourself.

   "...Anyways, long story short, we need Firefox to implement 'devicePixelContentBoxSize' before we can have pixel exact rendering, deterministically, in that browser."

That's just one example.

For something delicate like pixel-perfect rendering, every layer in the chain from hardware to OS -> libraryX -> libraryY -> libraryZ -> browser -> your code, all need to handle coordinates and thigs _perfectly_. If any one of those links in the chain messes things up, or doesn't provide the correct rounding, etc. then you are stuck.

It's not so terribly hard to do, but it has subtleties and edge cases, and everyone involved must handle them correctly. Also, if they handle them not-correctly, the result is still "good enough" for many purposes, so the fix doesn't get prioritized.

FWIW Firefox has supported that for a ~year now and you could fix it yourself it was just more work than the prebuilt way.

Ah, good to know. I'm not involved in that project, just had the link handy as a relevant discussion. I'll wait for the ShaderToy devs to fix it, I guess (:

Floats get rounded to an off-by-one pixel.

I'd be amazed to see a resolution/dpi combo that results in a 1 pixel error from rounding and equally amazed that it isn't far from the same combo that would cause a rounding error outside of a browser.

The issue in a browser is that you have a default zoom that is often not 100% and you can also "zoom" in/out of web pages which by will cause blurriness or overly sharp images. If you decide to ignore that in favor of the native resolution, then the content size is likely too big or small for what the user expects and it's not clear what the user wants it to look like or scale to even if you did implement that too because of the huge variety in screen sizes and ratios the content could be viewed from.

A native application does not generally have these issues because by nature of being native it was built for the form factor it is being used on.

Be it macOS, Windows, iOS, or Android they all have the same problem with native apps. There is nothing about code being native that changes the user wanting content on their device to be larger or smaller.

I find it to more about a thin line being rendered as a little bit of color in two adjacent lines of pixels. The result is a messy blur instead of a crisp line. If any layer of the libraries and APIs doesn’t pass up the coordinate system mappings, like say a window doesn’t report its exact screen space position to its content, then you lose access to the information to register the pixels precisely.

That can definitely happen between but as a loss of information between layers that don't support DPI fully (e.g. Windows 7 type DPI information which isn't per screen aware) or are intentionally ignoring physical pixel information (e.g. percentage based sized/positioned elements) not float precision loss. Float precision loss is definitely a thing but even a 32 bit float is integer perfect to 8,388,608 meanwhile a 7,640 pixel screen (1,000 times smaller) is considered extraordinarily large. Fractions close to 0 (such as APIs that use a 0-1 range for the screen or DPI represented a a percentage of a standard value) have a similar accuracy.

I'm not even sure on Windows there is a way to render anything

Reply on news.ycombinator.com