5 ms·

> Wayland has fractional scaling as a sort-of workaround if you can tolerate the entire screen being blurry. Every other major OS can deal with this. I think W

by jsheard 9mo ago

> Wayland has fractional scaling as a sort-of workaround if you can tolerate the entire screen being blurry. Every other major OS can deal with this. 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.

delta_p_delta_x 9mo ago
> 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/setting-the-default-dpi-awareness-for-a-process https://learn.microsoft.com/en-gb/windows/win32/hidpi/settin...
- n8cpdx 9mo 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.
  - delta_p_delta_x 9mo 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 https://serverfault.com/q/570785/535358
  - badsectoracula 9mo 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.
- PaulDavisThe1st 9mo 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
  - delta_p_delta_x 9mo 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.
tracker1 9mo ago
That's roughly what I did for my ANSI console/viewer... I started with EGA resolution, and each ega pixel renders 3x4 in its' buffer then a minor blur, then scaled to fit the render area. The effect is really good down to about 960px wide, which is a bit bigger in terms of real pixels than the original... at 640px wide, it's a little hard to make out the actual pixels... but it's the best way I could think of to handle the non-square pixels of original EGA or VGA... I went with EGA because the ratio is slightly cleaner IMO. It's also what OG RIPterm used.
amluto 9mo ago
I have precisely one Windows thing I use regularly, and it has a giant window that needs lots of pixels, and I use it over Remote Desktop. The results are erratic and frequently awful.

by jsheard 9mo ago

delta_p_delta_x 9mo ago

> 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/setting-the-default-dpi-awareness-for-a-process https://learn.microsoft.com/en-gb/windows/win32/hidpi/settin...

n8cpdx 9mo 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.
- delta_p_delta_x 9mo 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 https://serverfault.com/q/570785/535358
- badsectoracula 9mo 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.
PaulDavisThe1st 9mo 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
- delta_p_delta_x 9mo 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.

tracker1 9mo ago

That's roughly what I did for my ANSI console/viewer... I started with EGA resolution, and each ega pixel renders 3x4 in its' buffer then a minor blur, then scaled to fit the render area. The effect is really good down to about 960px wide, which is a bit bigger in terms of real pixels than the original... at 640px wide, it's a little hard to make out the actual pixels... but it's the best way I could think of to handle the non-square pixels of original EGA or VGA... I went with EGA because the ratio is slightly cleaner IMO. It's also what OG RIPterm used.

amluto 9mo ago

I have precisely one Windows thing I use regularly, and it has a giant window that needs lots of pixels, and I use it over Remote Desktop. The results are erratic and frequently awful.