←back to thread

Are We Wayland Yet?

(arewewaylandyet.com)
96 points picture | 2 comments | | HN request time: 0.002s | source
Show context
tastysandwich ◴[] 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 ◴[] 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 #
3np ◴[] No.32022047[source]
This is currently working fine for me with the wayland backend (not xwayland) on Firefox in sway. The details escape me but I think it started working properly since a release during the past ~6-9 months.

BTW, as a fellow long-time xmonad user who never managed to get fully used to the i3/sway tiling model I've been very happy so far switching to Qtile on my X11 machine. Took a couple of hours to replicate my decade-of-custom-crust Xmonad setup and another couple to add some new nice stuff I either wasn't able to or never bothered with (scratchpad/dropdowns for my top 5 frequently used apps like chat,pavucontrol,music,dashboards has already been a productivity improvement).

It seems to be on good track to work well in native Wayland mode as well, meaning we can have the same WM on both :)

replies(1): >>32022406 #
maxdamantus ◴[] No.32022406[source]
Right, the effective DPI switching works for Firefox on Wayland, but like all other applications on Wayland, fractional scaling will result in blurriness. I was looking into this less than 6 months ago, and I don't see any relevant updates since then and can see various other recent reports of the same issue.

The main applications I use are Firefox and some terminal emulator, so I would be happy as long as I can get both of those working using fractional scaling on either of Wayland/Xorg (without downscale blurring).

It doesn't work in Wayland due to limitations in the protocol and it doesn't work in Xorg simply because Firefox haven't implemented it there (and they seem to have closed the issue as WONTFIX, telling people to use Wayland instead, which has this issue that GGP raised).

It does work specifically in Xorg in Qt applications, though I don't actively use any of those.

replies(1): >>32022632 #
3np ◴[] No.32022632{3}[source]
output $MONITOR scale 1.25 in sway; no blurriness.

IIRC the only thing I eventually did to make things work was setting env vars

  MOZ_ENABLE_WAYLAND=1
  MOZ_WAYLAND_USE_VAAPI=1
(You probably already know this but check `window protocol` under about:config and/or use the xeyes method to verify that it's indeed not falling back to Xwayland. I mention this because any time I experienced blurriness, Xwayland's been in the loop and xeyes is a quick way to check that for any app)

As for terminals: foot has some weird behavior with font sizes[0] but kitty and alacritty have not had surprises here so far (though I didn't try alacritty in multi-DPI situation yet)

[0]: https://codeberg.org/dnkl/foot/issues/714

replies(2): >>32022946 #>>32027298 #
maxdamantus ◴[] No.32022946{4}[source]
I really don't think this is correct. It is possible that you're just not able to notice the blurriness due to the scaling method used, the resolution of the display and the fact that text rendering tends to be blurred nowadays anyway [0], but I'm 95% sure that you'll be looking at blurred output, as documented [1]:

> An integer is recommended, but fractional values are also supported. If a fractional value are specified, be warned that it is not possible to faithfully represent the contents of your windows - they will be rendered at the next highest integer scale factor and downscaled.

I've just tried it again myself and can observe the downscaling. I can provide screenshots later demonstrating the scaling artifacts if anyone is really interested.

[0] I configure my systems to perform crisper font rendering using `FREETYPE_PROPERTIES=truetype:interpreter-version=35`, along with some extra fontconfig options. This results in glyphs being aligned with actual pixel boundaries, reducing the need for antialias blurring.

[1] https://github.com/swaywm/sway/blob/445bc2a943d905a0e5b1dc60...

replies(1): >>32023349 #
3np ◴[] No.32023349{5}[source]
Maybe screenshots would be helpful!

Even so, downscaling (as opposed to upscaling which is what I think happens on Xwayland) while not "100%" should still not manifest as blurriness, though?

replies(1): >>32024677 #
1. maxdamantus ◴[] No.32024677{6}[source]
> Maybe screenshots would be helpful!

Okay, so for reference, here's how I normally see text rendered (I opt in to FreeType's v35 TTF interpreter, which hints (aligns) to full pixels rather than subpixels [0], which to me produces much clearer text than the now-default v40):

FTv35, Sway 1.00x, Firefox 1.00x: https://gist.github.com/Maxdamantus/2ba942eb20a58f0ec0708cac...

Here's how it looks again using the v35 interpreter, but scaled up to 1.25x, first using Sway [3] and second using Firefox (so in both cases the content text should be more-or-less the same size):

FTv35, Sway 1.00x, Firefox 1.25x: https://gist.github.com/Maxdamantus/2ba942eb20a58f0ec0708cac...

FTv35, Sway 1.25x, Firefox 1.00x: https://gist.github.com/Maxdamantus/2ba942eb20a58f0ec0708cac...

Using the v40 interpreter, the differences are harder to notice, but this is because the text has already been blurred due to extra horizontal antialiasing [1] [2], so blurring it a second time only makes the artifacts slightly worse instead of introducing new ones:

FTv40, Sway 1.00x, Firefox 1.25x: https://gist.github.com/Maxdamantus/2ba942eb20a58f0ec0708cac...

FTv40, Sway 1.25x, Firefox 1.00x: https://gist.github.com/Maxdamantus/2ba942eb20a58f0ec0708cac...

Even in the v40 images, the Firefox scaling looks better to me than the sway scaling. Additionally, the border around the text area is noticably clearer, since Firefox has intentionally drawn it to align with the pixel grid, but when it gets scaled by Sway, the correspondence between Firefox's pixel grid and the device pixel grid is lost.

Also note that all of these images have a sample of text in the bottom left corner that has been upscaled 800% with no/nearest interpolation, so the individual device pixels can be seen clearly.

If someone wants to download all of these images in one go:

  $ git clone https://gist.github.com/Maxdamantus/2ba942eb20a58f0ec0708cac7db92a9a
Admittedly, I should probably have reënabled subpixel antialiasing in the v40 examples, since the theory behind v40 kind of assumes subpixel antialiasing (maybe an exercise for a reader), but it should at least be clear from these images that the simulated fractional scaling that currently exists in sway/Wayland is suboptimal.

> Even so, downscaling (as opposed to upscaling which is what I think happens on Xwayland) while not "100%" should still not manifest as blurriness, though?

Yes. The downscale is done using "linear" interpolation (which averages/blurs adjacent pixels together—this is demonstrated in my v35 images by the grey vertical lines in text). sway also supposedly supports "nearest" interpolation, but this doesn't seem to work when I configure it, maybe it only does it when upscaling, not downscaling (I expect this would look worse anyway).

[0] https://freetype.org/freetype2/docs/hinting/subpixel-hinting...

[1] In fact, as I understand it, "super sample anti-aliasing" is when a graphic is rasterised to a larger image and then scaled down linearly, and this is what video game graphics attempt to approximate with "multisample anti-aliasing", so "antialiasing" really does imply "blurring"

[2] I feel I should also point out that this might make it hard to properly see the difference in clarity between the v35 images and v40 images for people that are already using simulated fractional scaling. Preferably the pixels in these images should be rendered directly to the viewer's device pixels.

[3] As discussed, the upscale to 1.25x in sway actually involves rendering at 2.00x and then scaling down by 0.625x, because 2*0.625 = 1.25

replies(1): >>32031444 #
2. 3np ◴[] No.32031444[source]
That is very insightful and you're on point!

I have to zoom in quite a bit and look closely to tell the difference and can still barely make out which one is better. Comparing with my setup (FF1.0/sway1.25) it looks different to both but perhaps that's due to different fonts or resolution. Anecdotally the performance here is better than your sway but worse than your FF. At this point it's similar to the difference between high and medium bitrate for an MP3 though - I might make out the difference if I focus but in no way does the lesser version affect my experience otherwise.

I guess this is semantics but I still wouldn't call it "blur", maybe "suboptimal downscaling".

That being said, I understand things like this affects us differently and that it's a valid issue for you and probably others - just like suboptimal audio encoding ruins the music listening experience for some.