Any news on fixing XWayland's blurry fractional scaling?

[Constancies]

Currently Firefox and Chromium default to X11, and require extra configuration to use Wayland. (though thankfully Firefox is just about to ship Wayland by default)

In addition, while running in the GNOME Shell,

• Discord
• Signal
• Slack
• Zoom
• Kate
• Krita
• Okular
• Elisa
• KDevelop
• Calibre
• Revolt
• REAPER
• MuseScore
• Ardour
• Element
• NeoChat
• Minecraft
• IntelliJ IDEA
• Visual Studio Code and Codium
• Kdenlive
• Authy
• Cider
• Steam
• every Steam game

all either rely on XWayland, support Wayland but not GNOME’s implementation due to lack of SSD support (namely KDE apps), or have experimental Wayland support that breaks certain functionality or comes with visual bugs (e.g. most of the cursor doesn’t display, or the title bar does not reflect whether the system is in light or dark mode). In other words, they rely on XWayland for a comfortable experience.

These were just the apps I could come up with off the top of my head, many of which I use on a daily basis. The amount of XWayland-only apps I use easily outnumbers the amount of Wayland-supported apps I use. I really hope there is a solution for this in the works, whether it be a toggle like in KDE Plasma’s system settings, or even a text file or extension that can be added to tell Mutter not to scale X11 apps–just about anything would be good by this point. I’m certain the majority of apps will eventually move over to Wayland, but I’m also certain that transition will take at least 5 years, and it will be a painful 5 years if this issue goes unaddressed.

And no, disabling fractional scaling and increasing the text size for the entire shell is not a good solution, because it will leave every GTK app with tiny UI elements that become very uncomfortable on the eyes to actually squint and look at. Which sort of defeats the point of scaling, in my opinion.

There is a reason why so many people have been asking for this. It is crucial that this works so users of 1440p displays can properly enjoy the GNOME shell without the majority of applications looking blurry and low-resolution, thereby defeating the point of a hi-dpi display. KDE has solved this nearly a year and a half ago–it would be great if the GNOME shell could either take after Plasma’s approach, or if we could at least see some development toward whatever alternate solution GNOME might want, like one that is able to detect whether or not an application is hi-dpi aware.

Thank you for reading. Any input or advice is appreciated.

[jfrancis (Jason Francis)]

@Constancies

KDE has solved this nearly a year and a half ago

That is not actually a solution because it still causes some apps to be broken. IMO, that toggle is going to be extremely confusing to most users and I am not sure why KDE thinks it is appropriate to ship that. There is no possible way you can switch it and have everything work correctly the way it is expected to.

The only real solution is to finish porting the apps to Wayland. Several of those apps listed are using Qt, Electron or SDL. It is not clear to me why those apps cannot use Wayland when these libraries have already gained Wayland backends years ago.

[jensgeorg]

The answer for Qt is probably most likely this one here:

Warning: Ignoring WAYLAND_DISPLAY on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.

It seems to be a deliberate choice when running on Mutter.

[Constancies]

IMO, that toggle is going to be extremely confusing to most users and I am not sure why KDE thinks it is appropriate to ship that.

Oh boy, if you think that’s confusing, just imagine how confused an Ubuntu user will be upon enabling fractional scaling on their shiny new 1440p laptop, just to find that most of their third party apps display incorrectly. Or, imagine the excellent UX of having to search online for a specific terminal command a Fedora newcomer would never think of to even enable fractional scaling. I can also see many of them spending several minutes trying to Google search a solution to the blurriness, only to learn that if they want a desktop that doesn’t have this bug, they should reinstall their system with KDE Plasma.

There is no possible way you can switch it and have everything work correctly the way it is expected to.

So therefore we should just leave every app looking blurry until Wayland support is finally solidified in 3 to 5 years, even though a solution for the vast majority of apps people use on a day to day basis is right here? Ok then.

Do not let perfect be the enemy of good.

Several of those apps listed are using Qt, Electron or SDL. It is not clear to me why those apps cannot use Wayland when these libraries have already gained Wayland backends years ago.

I do not know why they do not default to Wayland and when you are able to force them to use Wayland, have bugs. But I also don’t think the average user cares, nor do I. What they will see is that most of their apps aren’t working right, and will probably regard Linux as buggy and switch back to Windows, or something.

[jfrancis (Jason Francis)]

@Constancies

only to learn that if they want a desktop that doesn’t have this bug, they should reinstall their system with KDE Plasma.

No, this is not a solution because it only has choice of the same bug or a different bug. Please avoid restating the same points.

@Constancies

until Wayland support is finally solidified in 3 to 5 years,

I am not sure where you are getting these numbers, Wayland support for Electron, Qt and SDL is available now.

@Constancies

just imagine how confused an Ubuntu user will be upon enabling fractional scaling on their shiny new 1440p laptop, just to find that most of their third party apps display incorrectly […] I also don’t think the average user cares, nor do I.* What they will see is that most of their apps aren’t working right, and will probably regard Linux as buggy and switch back to Windows, or something.

The same thing will happen even with the toggle, all it does is cause some other apps to not work right. The reason Windows is a viable thing to switch back to is because apps actually got updated to correctly use the new-ish DPI aware APIs in Windows that does not have any of these issues. If this type of app compatibility is most important to you then IMO yes, you should switch back to Windows, KDE is not going to be a viable choice either.

Edit: Windows may not even be a solution, it may work correctly for those Electron apps that actually implement DPI awareness, for older non-DPI-aware apps it will still have the same problem where the app is forced to either have blurry scaling or it will be too small and unusable. This is just the price you pay for adding DPI awareness to a system that did not previously have it, everyone has to deal with it.

[mcatanzaro (Michael Catanzaro)]

I kinda think we are choosing the wrong bug, though. X11 applications can scale themselves without having to port to Wayland, but there’s nothing they can do if the compositor is scaling for them. Maybe users would be less upset by small applications than blurry applications?

[jfrancis (Jason Francis)]

@mcatanzaro

X11 applications can scale themselves

Not really because X11 still lacks a real API for this. The self-scaling these apps do is just a hack. At least with the scaling the apps are still usable despite having ugly blurring. If they are too small they can become unusable.

IMO the most comprehensive fix would be to do the following:

1. Create a new X11 extension for DPI awareness. Use the Wayland/Windows/MacOS APIs for inspiration.
2. Update every current X11 application and toolkit and window manager and panel and so on to use this new API.
3. For older applications, come up with some way to detect automatically if it can do its own scaling. Add some more code to the X server, cairo, toolkits to attempt to do this.
4. Figure out some reliable way to pass this as a setting from the desktop, so not just an environment variable but an actual API that knows how to identify X11 clients reliably. (Good luck)
5. Create a GUI that can configure this for every app, similar to what Windows does here.

6. Also make sure all of the above works with Wayland and doesn’t break it or supports the odd Wayland apps that don’t scale themselves. (rare, but they exist)
7. Test all of the above with every possible combination of X11 window manager and desktop and every user of XWayland. So the stalwarts who want CDE and Motif to work without blurring on their high DPI display can get it now too.

I don’t know what the hold up is with porting to Wayland or if it really would take multiple years, but I think the above steps would actually be a multiple years long effort. That is assuming the few people on earth who know how to do all of that and care enough about X11 even want to do it. And IMO step #4 is nearly impossible anyway. Compare to Wayland where the problem is already solved as well as fixing lots of other X11-only bugs, if these apps just finish their ports that are already mostly done anyway.

Addendum: As a tradeoff, this might also be possible by turning off scaling in XWayland and using multiple X servers each with their own scaling factor. But you still have to implement all of the above code, just now it has to live in a fork of Xephyr or an alternate XWayland version or something, instead of an extension.