Again I don't really know what you think you mean by 'blurred'? How do you think this is working?

If I tried all the possible scalings for my external monitor, the grey line around each window, to give a specific example of, is always a crisp physical one-pixel wide.

macOS creates a buffer to render to that is the same size as the physical output you're choosing to use, and is able to render with pixel precision in that buffer.

Would be easier if you said what scalings have you tried and what is your external monitor native resolution.

4k external monitor - here's HN at all the scalings https://imgur.com/a/QTrI6uJ. For example, look at the white box around the Y, that's always rendered precisely on hard physical pixel boundaries. It's one pixel for some scalings, then moves to two pixels for larger scalings. It's never a blur from a larger or smaller image that is then interpolated. It renders at the native resolution, knowing physical pixel boundaries, by the scaling of the render commands (the x and y to render at, before the render command runs) not an intermediate rendered image. (Remember to download the images so you aren't using browser interpolation to scale them.)

This looks pretty good. Though scaling in browsers has been mostly independent of corresponding OS features for quite a while. E.g. the issues mentioned above with Linux and fractional scaling do not affect browsers as much. The problem is usually with native UI elements, such as the settings app itself.

However, it is unclear to me what are the scaling ratios relative to the native resolution in your examples. In this article for Sierra you seem to be only able to pick integer factors: https://www.eizoglobal.com/support/compatibility/dpi_scaling...

> In this article for Sierra you seem to be only able to pick integer factors

Maybe? But that's ancient history.

I don't know what the ratios are - the UI doesn't expose them.

What does it expose? In Sierra as you can see from the screenshot it simply shows scaled resolutions. So you can just divide native resolution by the scaled to get the factor.

It looks like it treats them as 0.5 / 0.67 / 0.78 / 0.87 / 1.0 scaling (1080 / 1440 / 1692 / 1890 / 2160 for physical resolution of 2160).

But this is all a bit arbitrary - I think the macOS API deals with an abstract 'points' unit.

Great to know. Might make me reconsider that M1 Mac Mini option.

> It does not do 1.5 or 1.33 or 1.25 scaling, or does it blurred. Windows can handle any ratio.

Non-integer scaling (of a pixel source, vectors are different but not relevant here) either requires blending or crisp unequal-sizing artifacts.

In Mac OS, because that's how its scaling is designed. Windows does not have this problem, because it tells programs to render themselves at 1.33 or whatever and provides facilities to do it without pain in the ass. As the result scaling in Windows is painless with any displays at any resolutions. In fact, my main setup has two 1.25x DPI displays and an old 1x DPI display with zero blending or sizing artifacts excluding brief moments when you move a window from 1.25x display to 1x one until it lands.