Are We Wayland Yet?

My biggest annoyance at this stage is a few blurry apps when using fractional scaling. Eg Calibre & GIMP.

But I don't think that's Wayland's fault - it's up to those apps to upgrade their UI libraries (which might be a monumental task, I'm not sure).

I know GIMP is working towards GTK3 and hopefully that fixes the issue.

As for Calibre. It uses PyQT. Does anyone know if PyQT supports fractional scaling now? And what it would take for something like Calibre to upgrade to a newer PyQT version?

> But I don't think that's Wayland's fault - it's up to those apps to upgrade their UI libraries (which might be a monumental task, I'm not sure).

Actually, it is Wayland's fault[0], and arguably Xorg is able to handle it better[1].

Basically, the protocol doesn't currently support sending a fraction as the scale to the application, so whenever you've got displays with DPIs that are not integer multiples of one another, the compositor will scale down on at least one of those displays, causing blur. In Xorg, it is normal for applications to simply detect the DPI of the display they're on and render accordingly. In either case, it requires support from the graphical framework used by the application (eg, Qt applications seem to automatically handle this on Xorg).

I would quite like to replace one of my monitors in a multi-monitor setup with a HiDPI one, but lack of support for this is what's holding me back. I'd be happy enough if Firefox just added support to Xorg for DPI detection[2], though if Wayland gets this working first, I'll probably switch over to that (I've gone back and forth between Xorg/xmonad and Wayland/sway, and I don't really see any other blockers for me).

[0] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i...

[1] https://www.reddit.com/r/kde/comments/lficfe/wayland_fractio...

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1679335

I’m fairly sure it only happens on XWayland windows, and that in general it is not possible to fractional scale something without the aid of the client. OSX also has a similar restriction where only integer scaling is allowed (but it is less of a problem there due to higher resolutions in general).

There is fractional scaling though under Wayland which works fine for Wayland applications.

This is not limited to XWayland windows. See the relevant issues:

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i...

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i...

It turns out there has been some activity recently, but this seems to all be in the form of draft PRs:

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...

You are correct in saying that it requires support from the client. This is even the case for integer scaling, which is why it's unfortunate that there's a protocol and clients that are specifically designed around integer scaling without addressing fractional scaling.

Integer scaling has already been implemented and doesn't result in pixel-snapping artifacts and broken text rendering. I fear that fractional scaling will result in exactly this, similar to CSS 1.0.

The OSX solution is the only one that will avoid insane complexity at all levels (protocol, compositor, and client), and as demonstrated by OSX, can work fine in a mixed-DPI environment.