I think Windows is the only other one which really does this properly, macOS also does the hack where they simulate fractional scales by rendering with an integer scale at a non-native resolution then scaling it down.
Windows is the only one that does this properly.
Windows handles high pixel density on a per-application, per-display basis. This is the most fine-grained. It's pretty easy to opt in on reasonably modern frameworks, too; just add in the necessary key in the resource manifest; done. [1]
Linux + Xorg has a global pixel density scale factor. KDE/Qt handles this OK; GNOME/GTK break when the scaling factor is not an integer multiple of 96 and cause raster scaling.
Linux + Wayland has per-display scaling factors, but Chromium, GNOME, and GTK break the same way as the Xorg setup. KDE/Qt are a bit better, but I'm quite certain the taskbar icons are sharper on Xorg than they are on Wayland. I think this boils down to subpixel rendering not being enabled.
And of course, every application on Linux in theory can handle high pixel density, but there is a zoo of environment variables and command-line arguments that need to be passed for the ideal result.
On macOS, if the pixel density of the target display is at least some Apple-blessed number that they consider 'Retina', then the 'Retina' resolutions are enabled. At resolutions that are not integer multiples of the physical resolution, the framebuffer is four times the resolution of the displayed values (twice in each dimension), and then the final result is raster-scaled with some sinc/Lanczos algorithm back down to the physical resolution. This shows up as ringing artifacts, which are very obvious with high-contrast, thin regions like text.
On non-retina resolutions, there is zero concept of 'scaling factor' whatsoever; you can choose another resolution, but it will be raster-scaled (usually up) with some bi/trilinear filtering, and the entire screen is blurry. The last time Windows had such brute-force rendering was in Windows XP, 25 years ago.
[1]: https://learn.microsoft.com/en-gb/windows/win32/hidpi/settin...
How can you say this when applications render either minuscule or gigantic, either way with contents totally out of proportion, seemingly at random?
I don’t have to pull out a magnifying glass to notice those issues.
Right-click on the `.exe`
Properties
Compatibility tab
Change settings for all users
Change high DPI settings
Under 'High DPI scaling override' section, tick box for 'Override high DPI scaling behaviour. Scaling performed by'
In the drop-down box below, select 'Application'
For MMC snap-ins like `diskmgmt.msc`, `services.msc`, or `devmgr.msc`, there's a Registry key you can set. See this ServerFault question: https://serverfault.com/q/570785/535358
The thing is X11/Xorg can also theoretically do the same thing (and most likely Wayland too) but it needs, you guessed it, application (and window manager / compositor) support.
This is not our [0] experience. macOS handles things on a per-section-of-window, per-application, per-display basis. You can split a window across two monitors at two different DPIs, and it will display perfectly. This does not happen on Windows, or we have not found the right way to make it work thus far.
[0] ardour.org
No, it does not. If you have two displays with different physical pixel densities, and especially if they are sufficiently different that Apple will consider one 'Retina' and 'not Retina' (this is usually the case if, for instance, you have your MacBook's display—which probably is 'Retina'—beneath a 2560 × 1440, 336 × 597 mm monitor, which is 'not Retina'), then the part of the window on the non-Retina display will be raster-scaled to account for the difference. This is how KDE Plasma on Wayland handles it, too.
In my opinion, any raster-scaling of vector/text UI is a deal-breaker.
Actually, the default in MacOS is that the window is only on one monitor, and its the monitor where the cursor was when you last moved the window, so you might have a window appearing invisible because you dragged it near the corner and some sliver ended on another monitor.
Look at this complicated tinkering MacOS makes you do for something as simple as spanning windows across monitors! https://www.arzopa.com/blogs/guide/how-to-make-a-window-span... (OK this last part is slightly facetious but Linux gets dinged for having to go into menus because the writer wants something to work the way it does in on other operating systems the whole time)
I don't think this is true. I use non-integer scaling on my Mac since I like the UX to be just a little bit bigger, and have never observed any kind of ringing or any specific artifacts at all around text, nor have I ever heard this as a complaint before. I assume it's just bilinear or bicubic unless you have evidence otherwise? The only complaint people tend to make is ever-so-slight additional blurriness, which barely matters at Retina resolution.
[1]: https://en.wikipedia.org/wiki/Display_Stream_Compression
There are a few Reddit threads that crop up when one searches for 'macOS ringing artifacts scaling'. For instance, these ones:
https://www.reddit.com/r/macbookpro/comments/1252ml8/strange...
https://www.reddit.com/r/MacOS/comments/1ki58zk/fractional_s...
https://www.reddit.com/r/MacOS/comments/l8oadr/macos_fringin...
All are ringing artifacts, typical of downscaling. I no longer have a Mac (chose one for work to try it out, saw this issue, returned it immediately), but I assure you this is what happens.
> The only complaint people tend to make is ever-so-slight additional blurriness
At no scale factor should there be any blurriness unless a framebuffer resolution is explicitly set. The 'scale factor' should be entirely independent of the physical resolution, which macOS simply does not do.
Apple's understanding and implementation of 'Retina' comes from a singular source: the straightforward doubling in each dimension of the display resolution of the iPhone 4 compared to the iPhone 3GS. It has not changed since, and has applied this algorithm throughout its OS stack.
Like I said, absolutely nothing like that happens on my display. I see the ringing in the first link. That doesn't happen to me. Not even a hint of it.
I get you don't like the scaling, but like I said, the very slight blurriness just isn't really noticeable in practice, especially given how Macs antialias text to begin with. Of all my complaints about Macs, this particular one is close to the bottom.
So I took my Mac Mini, hooked up to a 4K monitor, verified there were no DSC artifacts at native resolution, set it to "2560x1440" and sure enough the same artifacts appeared for me too, but still no telltale signs of DSC. So yeah, I gotta say, this is on Apple. Between this and dropping subpixel antialiasing support for text, it's pretty clear that their only properly supported configuration is 2x scaling on high-DPI displays.
OK, I just grabbed my loupe to make sure I'm not missing anything, and pulled up an app in dark mode (so ringing should be more visible) on my MBA M4. I'm using its built-in display. I've cycled through all 4 available resolution settings in Display, and absolutely zero artifacts or ringing. Then tried connecting to my LG UltraFine 4K which connects over Thunderbolt, that gives 5 resolution settings instead of 4, and zero artifacts/ringing on any of those either.
So I have no idea what's going on. I don't doubt that you're seeing it, and it's there in that Reddit photo. But maybe it's something specific to external monitors over a certain connection type or something? Seems very strange that Apple would use a different downsampling algorithm under different circumstances though.
I'd normally assume the most likely culprit would be some kind of sharpening setting on a monitor, as that can absolutely cause the type of ringing seen in that Reddit photo. But on the other hand, if you're testing it right now and not seeing it at native 2x, then that would seem to be ruled out, at least in your case. Maybe it's some kind of resolution negotiation mismatch where it's actually the monitor applying a second scaling that has ringing, since monitors can accept signals that don't match their native hardware resolution?
* = You have to go click "Advanced...", enable "Show resolutions as list", then when back on the main Displays page, enable "Show all resolutions", to get this and many other options -- but this is only necessary on the internal display, the external display offers "2560x1440" as a non-advanced choice
This happens on the native displays of MacBooks and iMacs, too. Try any of the 'looks larger'/'looks smaller' settings and it'll show up.
For the record, this isn't just visual. Rasterising to a framebuffer that is considerably larger than the physical resolution and then scaling produces a tangible effect on battery life. Not that it matters much with the impressive efficiency of the M-series SoCs, but it is there nonetheless.
You seem to be fundamentally misunderstanding. Yes, raster scaling is how it works. I haven't disputed that anywhere.
I'm saying the ringing artifact specifically that you're complaining about is not happening on my setup, nor does it seem to be widespread. You were complaining about the specific Lanczos algorithm due to its noticeable ringing, I'm saying that therefore doesn't seem to be the algorithm being used on mine, nor is there any documentation that's the algorithm Apple uses. Your criticism seems to be based on partially wrong information, even if something like it seems to happen on certain external displays -- whatever it is, it's not a universal problem.
If you somehow missed my other comment, please read it:
Is this more of an aspirational thing, like Windows supports "doing it right", and with time and effort by the right people, more and more applications may be able to be drawn correctly?
[edit] I guess so, I see your comment about setting registry keys to make stuff work in Microsoft's own programs. That aligns more closely with my experience.
I think Android does it properly too because they have to handle an entire zoo of screen sizes and resolutions there. Although they don't have the issue of dealing with subpixel rendering.
To be fair, UXGA was a thing 20 years ago. I don't think it makes sense for Apple to care all that much about low DPI monitors. They don't sell any, and they wouldn't be acceptable to most Apple people, who have had crisp displays available for > 10 years now. I wouldn't be surprised if the number of Apple users on low dpi is single digit percentage.