| > 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... |
| |
| ▲ | crazygringo 3 hours ago | parent | next [-] | | > 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. | | |
| ▲ | kbolino 2 hours ago | parent | next [-] | | 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 | |
| ▲ | delta_p_delta_x 2 hours ago | parent | prev [-] | | > 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. | | |
| ▲ | crazygringo an hour ago | parent [-] | | 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. | | |
| ▲ | kbolino an hour ago | parent | next [-] | | 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. | | |
| ▲ | crazygringo 34 minutes ago | parent [-] | | Huh, very interesting. 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? |
| |
| ▲ | delta_p_delta_x 26 minutes ago | parent | prev [-] | | > 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. | | |
| ▲ | crazygringo 8 minutes ago | parent [-] | | I've repeatedly explained that's not the case. Not on any Mac I've ever owned, and I already explained I thoroughly investigated my current M4 MBA. It's not showing. |
|
|
|
| |
| ▲ | PaulDavisThe1st 5 hours ago | parent | prev | next [-] | | > 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 | | |
| ▲ | delta_p_delta_x 4 hours ago | parent | next [-] | | > 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. | |
| ▲ | Macha 3 hours ago | parent | prev [-] | | 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) |
| |
| ▲ | Gracana 2 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | n8cpdx 5 hours ago | parent | prev [-] | | > 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. | | |
| ▲ | delta_p_delta_x 4 hours ago | parent | next [-] | | 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 | |
| ▲ | badsectoracula 4 hours ago | parent | prev [-] | | 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. |
|
|
