> HOWEVER, and I hope this is a transient situation, there is a problem: in GNOME, applications that aren’t native Wayland apps don’t scale nicely.
Transient situations are almost permanent in Linux land. This has been a problem for a long time and I don't see a solution coming in the near future. But maybe I'm wrong (I hope so!).
This is an issue with any software that tries to maintain backwards compatibility, not Linux. Windows has:
- Many years worth of different control panels.
- Little consistency with respect to toolkits in general.
- Fractional scaling issues in applications using older toolkits (e.g., open up the policy editor and notice the blurry fonts). Microsoft is actually giving up here and has been experimenting with ML-based scaling for old applications (an approach I expect we'll eventually see in Linux as well).
Apple handles this by breaking compatibility every so often, forcing old software out of the picture.
Window's backward compatibility is way better though. There are plenty of GNOME extensions and applications that just don't work anymore under modern GNOME Wayland.
Example: all the redshift applications and extensions for lowering the screen brightness.
It's seemed a little odd to me, particularly given Linus' attitude of "never break userspace", that so many high-profile projects decide to break backwards compatibility almost for the sake of it (particularly GTK/GNOME).
I notice that even the blurry scaling on Windows looks better than what we have on Linux. It seems that they have some special algorithm for that. Anyone who knows how it is implemented can chime in here?
The only part that's not going to be available for a while is fractional scaling in GTK and old Qt5 software needs to update to Qt6. Everything else is rather quickly falling in place. GNOME in its stereotypical fashion doesn't seem to want to support fractional scaling and doesn't want to provide QoL features like not making XWayland apps blurry, but that's not a problem with Wayland per se.
Well, I'm glad to be proven wrong. That still looks to be a downsampling method rather than just not applying the scale and using Xft.dpi though, but that can have advantages in multi-dpi setups I guess.
This. naively it seems to be a real straightforward to fix. Just scale to the next integer and then downscale. It won't be as pretty but it will be much better then what we have now. Hell make the scale factor configurable so you can get real smooth graphics.
Transient situations are almost permanent in Linux land. This has been a problem for a long time and I don't see a solution coming in the near future. But maybe I'm wrong (I hope so!).