>> My kingdom for Wayland fractional scaling that doesn’t make my apps blurry.
I'm convinced I don't understand this thing. I feel like it's NOT the compositors job to scale the pixels of an application. That might be a good hack for super high resolution screens with applications that don't know how to handle high DPI but it's an inferior solution. Scaling text at the pixel level is going to be inferior to rendering it at higher resolution to start with.
So how does it work? Do we have per-monitor setting for scale factor, and both the DE and the apps need to follow it for idea behavior? And the compositor scaling the apps is a stopgap? Is that it, or is there more to this?
Let me type down what I learned through many hours of research.
Under a Wayland compositor, there are basically three types of apps.
1. XWayland apps which cannot use Wayland's scaling protocols, but may be able to use Xft.dpi to scale themselves. Examples include Electron apps when not running on Wayland and later versions of Qt5. These will work without blurriness but they cannot support proper multi-dpi support. The Wayland compositor has no way of detecting whether it actually scales. Some compositors (KDE, Hyprland) let you not scale them, but others (GNOME) will make them super blurry because they are rendered at 96 DPI and stretched to the needed scale. GTK3 notably never supported fractional scaling on X11.
2. Wayland apps which supports integer scaling only. Examples include GTK3, GTK4, Qt5 apps, Mozilla Firefox (minus the experimental fractional scaling feature, which is very buggy). When compositor wants to render at a fractional resolution, the app will render at the nearest integer scale, and the compositor will downsample it. These don't look ideal, but aren't super blurry either, and will work properly with multi-dpi monitors.
3. Wayland apps which properly support fractional scaling via wp-fractional-scale-v1. This is a recent addition to the protocol, so not widely supported yet. The only toolkit that supports it is Qt6, but Chromium (incl. recent Electron apps in Wayland mode) also supports it. Some terminal emulators do too. This results in pixel perfect rendering and looks ideal and works properly with multi-dpi monitors.
Downsampling works well on Macs which have high resolution screens such that you mostly use at least 175% scaling. At lower scales such as 125% (e.g. 1080p 13-14 inch laptops) and 150% (e.g. 1440p 14-16 inch devices), the degradation is fairly obvious if you use smaller fonts. This also breaks subpixel rendering (Macs haven't had it for a long time), which is important for making fonts look good on lower DPI screens. In some ways, Wayland scaling is a regression for KDE because Qt5 had proper fractional scaling for some time under X11, which was not implemented in Wayland as the protocol came out after Qt5 lost support.
The toolkits would need to add that, and some of them had engineering direction incompatible with such an idea.
Especially GTK 3, which was incompatible (by default) with anything that didn't resemble the imagined wayland future, including non RGBA8888 displays or systems with different GL and X11 visuals.
Not design. Engineering direction. People problem, instead of computer problem, to be quite honest. And one of those directions was that there was no other output than blitting RGBA8888 to screen (which was at one point the only format expected to be seen with Wayland, and GTK3 already was driving towards Wayland) - potentially accelerated with OpenGL (which had hilarious results on some chips where GL pipeline was 16bit only while 2D was 24bit).
Also, unless you're running Xsgi, it's not a given that every app is scaled by compositor.
Honestly, the right way was always to not assume any given DPI, and instead have every top-level window be DPI-aware and have the toolkit update that information dynamically.[1] Or optionally go all-in on vector dpi-independent approach.
[1] The only correct way to handle hi-dpi on Win32 GDI, where scaling is broken partly by old GDI assumption that DPI didn't change, and by applications that hardcoded 96 dpi
There must be more categories than this because Qt 5 on Wayland can do fractional scaling since some years, you may need to set QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough.
Since some years? I don't think so. wp-fractional-scale-v1 was merged only like 1 year ago. The only more recent version of Qt5 is 5.15 and on the release notes I don't see any Wayland changes.. Any reference you have for that?
Apps that natively support fractional scaling will not be scaled by the compositor. (Well unless they span multiple monitors with different scales IIUC.) Scaling is just a fallback for apps that don't support fractional scaling or edge cases like you drag a non-responding app onto a monitor with a different scale.
Yes, you can have a per-monitor scale factor and apps should render at the right scale based on where they are positioned.
I'm convinced I don't understand this thing. I feel like it's NOT the compositors job to scale the pixels of an application. That might be a good hack for super high resolution screens with applications that don't know how to handle high DPI but it's an inferior solution. Scaling text at the pixel level is going to be inferior to rendering it at higher resolution to start with.
So how does it work? Do we have per-monitor setting for scale factor, and both the DE and the apps need to follow it for idea behavior? And the compositor scaling the apps is a stopgap? Is that it, or is there more to this?