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