←back to thread

Are We Wayland Yet?

(arewewaylandyet.com)
96 points picture | 3 comments | 07 Jul 22 22:22 UTC | HN request time: 0.832s | source
Show context
tastysandwich ◴[07 Jul 22 23:18 UTC] No.32020935[source]▶
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?

replies(3): >>32021085 #>>32021171 #>>32021261 #
maxdamantus ◴[07 Jul 22 23:54 UTC] No.32021261[source]▶
> 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

replies(3): >>32022047 #>>32022079 #>>32023293 #
kaba0 ◴[08 Jul 22 04:44 UTC] No.32023293[source]▶
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.

replies(1): >>32023328 #
1. maxdamantus ◴[08 Jul 22 04:48 UTC] No.32023328[source]▶
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.

replies(1): >>32023593 #
2. tadfisher ◴[08 Jul 22 05:23 UTC] No.32023593[source]▶
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.

replies(1): >>32027868 #
3. maxdamantus ◴[08 Jul 22 21:56 UTC] No.32027868[source]▶
The problem is that this is what currently happens when people enable fractional scaling (ie, setting the scale to 1.5 rather than 2), which I'm fairly sure is common.

Try running a web browser with fractional scaling, open up a JS console, and look at the values for `devicePixelRatio` and `innerWidth`. You'll probably see that the former is an integer (particularly, the ceiling of your configured scale, eg, 2), and the latter is wider than the actual number of device pixels. This means the web browser is rasterising to a larger size and then being downscaled.

Unless the rasterisation size is an integer multiple of the final pixel size (which it's not), there will be unavoidable "pixel-snapping artifacts". This is basically the whole premise behind vector graphics. You wouldn't use a bitmap font that's been scaled down to the right size, but this is effectively what happens when viewing text on Wayland with a non-integer scale.