Comment by hollerith
6 hours ago
Wayland supports it (and Chrome supports it very well) but GTK does not. I run my UI at 200% scaling because graphical Emacs uses GTK to draw text, and that text would be blurry if I ran at my preferred scaling factor of 150% or 175%.
This works with GTK for me at least. I've been using Gnome+Wayland with 150% scaling for almost 4 years now, and I haven't noticed any issues with GTK. Actually, my experience is essentially backwards from yours—anything Electron/Chromium-based needed a bunch of command-line flags to work properly up until a few months ago, whereas GTK apps always just worked without any issues.
If you're using a high-DPI monitor, you might not notice the blurriness. I use a standard 110-DPI monitor (at 200% scaling in Gnome) and I notice it when the scaling factor is not an integer.
Or more precisely, I noticed it eventually as a result of my being primed to notice it after people on this site insisted that GTK cannot handle fractional scaling factors.
Compared to the contents of a browser's viewport, Emacs and the apps that come with Gnome are visually simple, so it took me a year or 2 to notice (even on a standard 110-DPI monitor used at 150% and 175% scaling) any blurriness in those apps since the app I'm most conditioned to notice blurriness is my browser, and Chrome's viewport is resolution independent except when rendering certain image formats -- text is always non-blurry.
Yes, Chrome's entire window can be quite blurry if Xwayland is involved, but it now talks to Wayland by default and for years before that could be configured to talk Wayland, so I don't consider that worth talking about. If Xwayland is not involved, the contents of Chrome's viewport is non-blurry at all scaling factors except for the PNGs, JPGs, etc. For a long time, when run at a fractional scaling factor under Gnome (and configured to talk Wayland) the only part of Hacker News that was blurry was the "Y" logo in the top left corner, then about 2 years ago, that logo's PNG file was replaced with an SVG file and the final bit of blurriness on HN went away.
> If you're using a high-DPI monitor [...] I use a standard 110-DPI monitor (at 200% scaling in Gnome)
FWIW, I'm using a 184 DPI monitor with 150% scaling.
> you might not notice the blurriness. [...]
> Compared to the contents of a browser's viewport, Emacs and the apps that come with Gnome are visually simple, so it took me a year or 2 to notice
I'm pretty sensitive to font rendering issues—to the point where I've complained to publishers about their PDFs having unhinted fonts—so I think that I would have noticed it, but if it's really as subtle as you say, then maybe I haven't.
I do have a somewhat unusual setup though: I'm currently using
although that might not be required any more with recent versions. I've also enabled full hinting and subpixel antialiasing with Gnome Tweaks, and I've set the following environment variables:
So maybe one of those settings would improve things for you? I've randomly accumulated most of these settings over the years, so I unfortunately can't really explain what (if anything) any of them do.
> Yes, Chrome's entire window can be quite blurry if Xwayland is involved, but it now talks to Wayland by default
Ah, good to hear that that's finally the default; that probably means that I can safely remove my custom wrapper scripts that forced those flags on.
GTK uses Pango/Harfbuzz and some other components to draw text, all of which are widely used in other Linux GUI stacks. GTK/GDK do not draw text themselves, so your complaints are not with them directly.
I'm not asseting that text is being rendered incorrectly. I'm asserting that after rendering, the text is being downsampled.