Comment by delta_p_delta_x

> I think Windows is the only other one which really does this properly

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...

PaulDavisThe1st 4 days ago

> Windows is the only one that does this properly. Windows handles high pixel density on a per-application, per-display basis.

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

Reply View 3 replies

delta_p_delta_x 4 days ago

> macOS handles things on a per-section-of-window, per-application, per-display basis.
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.

Reply View | 1 reply
- sunnyps 4 days ago
  
  I think the only case where raster scaling is not a deal breaker is a window spanning high and low DPI displays. That is unless the app delegates compositing to the OS compositor which could then raster the contents at the different scales correctly. Not all content can be delegated to the OS - video games for example.
  
  Reply View | 0 replies
Macha 4 days ago

I think there’s one group of people who consider preserving the physical dimensions important that like the macOS approach. For me, if a window is across multiple displays then it’s already broken up and I’m not too bothered about that. What I care about is getting application UI to a reasonable size without blurring. MacOS doesn’t do that.
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)

Reply View | 0 replies

crazygringo 4 days ago

> 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.

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.

Reply View 10 replies

kbolino 4 days ago

Indeed, these artifacts sound like they're coming from Display Stream Compression [1] rather than scaling. I've had Macs occasionally use DSC when it wasn't necessary; power-cycling the display and/or changing the port it's plugged into usually fixed it. If it's consistently happening, though, it's probably because the display, the cable, the port, and/or the GPU can't handle the resolution and refresh rate at full bandwidth.
[1]: https://en.wikipedia.org/wiki/Display_Stream_Compression

Reply View | 0 replies
delta_p_delta_x 4 days ago

> ringing or any specific artifacts at all around text
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.

Reply View | 8 replies
- crazygringo 4 days ago
  
  All of these involve external monitors as far as I can tell, so it seems more likely it's the Display Stream Compression mentioned by the sibling to your comment that is the culprit.
  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.
  
  Reply View | 7 replies
  
  kbolino 4 days ago
  
  I gotta say, as the guy who brought up DSC, that last Reddit post especially had me doubting. That is not what DSC artifacts look like. DSC subsamples the chroma, which causes distinct color bleeding issues. That is luma bloom, which doesn't happen with DSC.
  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.
  
  Reply View | 2 replies
  
  delta_p_delta_x 4 days ago
  
  > All of these involve external monitors as far as I can tell
  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.
  
  Reply View | 3 replies

sunnyps 4 days ago

ChromeOS also does fractional scaling properly because Chrome does it properly. The scaling factor is propagated through the rendering stack so that content is rastered at the correct scale from the beginning instead of using an integer scaling factor and then downscaling later. And it takes subpixel rendering into account too, which affects things like what elements can be squashed into layers backed by GPU textures.

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.

Reply View 0 replies

Gracana 4 days ago

This is a surprising opinion to encounter, given my experience with scaling on Windows, where simple things like taking my laptop off its dock (going from desktop monitors to laptop screen) causes applications to become blurry, and they stay blurry even when I've returned the laptop to the dock. Or how scaling causes some maximized window edges to show up on the adjacent screen. Or all manner of subtle positioning and size bugs crop up.

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.

Reply View 1 reply

AgentMatt 4 days ago

Not sure about the underlying reason, but I use Windows for work and the only program I've encountered in the past two years with this behavior is the Eclipse IDE. Everything else deals very well with rescaling and docking / undocking to 4k displays.

Reply View | 0 replies

n8cpdx 4 days ago

> Windows is the only one that does this properly.

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.

Reply View 2 replies

delta_p_delta_x 4 days ago
These were probably written against the old-school Win32. It's pretty easy to fix.
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'
Done.
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
Reply View | 0 replies
badsectoracula 4 days ago

The 'doing it right' part is from how it should be done, but it still needs application support.
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.

Reply View | 0 replies

nomel 4 days ago

> The last time Windows had such brute-force rendering was in Windows XP, 25 years ago.

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.

Reply View 0 replies