#295 Improve GTK4 font rendering by default for 1080p displays.
Closed: Fixed 2 years ago by catanzaro. Opened 2 years ago by nickavem.

Related upstream bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/3787
RHBZ issue: https://bugzilla.redhat.com/show_bug.cgi?id=1943794

Currently, on F36, GTK4 font rendering looks poor by default on 1080p displays (and probably anything with a lower resolution). A few comparisons can be seen in this forum post: https://ask.fedoraproject.org/t/whatss-with-the-new-poor-font-rendering-in-gtk4/20919

Considering a lot of, if not most Fedora users do not use HiDPi displays, and that this issue is still very controversial and “up in the air” upstream, Fedora should take the slightly more conservative approach and enable grayscale anti-aliasing by default for people with 1080p displays, at least until the upstream issue is resolved. This can be done simply using this config option: https://gitlab.gnome.org/GNOME/gtk/-/issues/3787#note_1280247

Perhaps there is a way to automatically detect whether a display is >1080p (and I believe that is part of what is being considered upstream) but for now, I think it would be most applicable to simply enable it globally by default. Most users having to change a config file to make their apps look ok is unacceptable. And in the short term, this will not make nearly as much of a difference for HiDPi displays as the default does for Mid- or LoDPi displays.


A few considerations:

  • Fedora 36 is the first release to significantly use GTK 4 apps, so previously this was not an issue
  • The suggested change is going to make Fedora 36 look a lot better; the quality improvement is so drastic that the usual "font rendering is subjective" comments lose a lot of their usual weight

But:

  • If we do this, it becomes much less likely that somebody will try to help fix the problem
  • Matthias maintains this code, and his opinion should count for a lot here
  • If we do this, it becomes much less likely that somebody will try to help fix the problem

I agree with everything except this. Seems like lots of work is already being done upstream. Can you CC the maintainer, as I am not certain how to on pagure 😅

and enable grayscale anti-aliasing by default for people with 1080p displays

Grayscale looks worse than rgb on my lowdpi monitors, my 2 cents.

and enable grayscale anti-aliasing by default for people with 1080p displays

Grayscale looks worse than rgb on my lowdpi monitors, my 2 cents.

This may be very well true for GTK3 on some LCD screens, but GTK4 is currently incapable of traditional RGB rendering.

+1. After installing Fedora 36, the only problem was poor font rendering (fixed by https://discussion.fedoraproject.org/t/beautify-fedora-36-and-gnome-42/37943#better-font-rendering-1)

Metadata Update from @catanzaro:
- Issue tagged with: meeting-request

2 years ago

Metadata Update from @chrismurphy:
- Issue untagged with: meeting-request
- Issue tagged with: meeting

2 years ago

The last round of fixes to font rendering in GTK4 is here:

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4429

I misspoke in the meeting - it was Marek, not Milan, who fixed kerning.

I'm not sure whether that's good place but… Does anyone know what's the difference between Fedora system configuration (GTK4, pango, fontconfig, etc.) and that one from GNOME OS and Flatpak (probably Freedesktop Runtime). In Fedora 35 and Fedora Rawhide fonts are blurry on low-DPI but on GNOME OS and also on Flatpak apps (running in Fedora), fonts are clear and sharp (better than GTK3).

Does changing to hinting have any effect on hi-dpi displays? I don't have that hardware here, so am unable to test myself.

Does anyone know what's the difference between Fedora system configuration (GTK4, pango, fontconfig, etc.) and that one from GNOME OS and Flatpak (probably Freedesktop Runtime).

Fedora has cairo 1.17. The Freedesktop SDK has cairo 1.16.

Now that we have screenshots, do we have everything we need to make a decision on this issue? If yes, I'll schedule it for the next meeting when @mclasen is around, probably August 2nd.

Now that we have screenshots, do we have everything we need to make a decision on this issue? If yes, I'll schedule it for the next meeting when @mclasen is around, probably August 2nd.

Maybe we should call in more font experts for opinions? @behdad perhaps?

The upstream issue has a record of some feedback I received from Nikolaus Waxweiler. He suggested we should do both subpixel positioning and hinting: https://gitlab.gnome.org/GNOME/gtk/-/issues/3787#note_1261139. From myself in that issue: "FreeType v40 hinting affects the vertical axis only, whereas subpixel positioning affects the horizontal axis only. FreeType already knows not to hint horizontally so as not to mess with subpixel positioning. Correct? So that doesn't seem like a very good justification at all for disabling vertical hinting?" However, I asked Matthias and he indicated this would require major changes that nobody has volunteered to implement.

Personally, the screenshot with hinting enabled looks clearly superior to me. Switching back to hinting would resolve a bunch of user complaints. But I'm not very comfortable with overriding upstream's defaults. Maybe we can find a way forward with further discussion.

Personally, the screenshot with hinting enabled looks clearly superior to me. Switching back to hinting would resolve a bunch of user complaints. But I'm not very comfortable with overriding upstream's defaults. Maybe we can find a way forward with further discussion.

Hi, I have done a lot of testing of font rendering on different desktop environments, and have something to contribute here. Linus has referred to "fragmentation" in the Linux desktop, and font rendering is affected by many factors. The perfect example is GTK apps on KDE Plasma Wayland. Even if you set sub-pixel AA in Settings, GTK AA will be grey scale. However, if you symlink the conf file for your sub-pixel layout, IE 10-sub-pixel-rgb.conf, it will enable it on GTK. Notably, this only affects the Wayland session.

I believe this may also part of upstream's concern. Part of libadwaita's mission is to be the standard. That is compromised if you allow variables in other systems to affect your UX. GTK4 settings overall are less user-facing, and sub-pixel antialiasing requires knowledge of the monitor layout. Set to RGB by default + non-standard layout = bad fonts.

That said, there needs to be an option to enable it, or GNOME (and by extension Fedora), will look objectively worse for most users around the world. I can believe it is non-trivial to make it fit with libadwaita, but the ability to change font anti-aliasing is important. If you look at Gecko Linux or posts about Ubuntu font quality, it's also clearly a non-trivial problem. If anti-aliasing itself exists in GTK4, then we would just need a way to implement the equivalents of 10-sub-pixel-rgb/vrgb/etc.conf and 11-lcdfilter-default.conf, and a way for the former to be user-selected. If "sub-pixel positioning" is a totally different mechanism and grey scale AA is not built into GTK4, then it's harder.

Lastly, I'm torn on how bad a decision it is to be unaffected by system font settings. It's bad because it detracts from user experience. However, there are a lot of inconsistencies in how those settings get applied to the rest of the system. QT on GTK, GTK on QT, Wayland vs X. Is the conf file for that setting symlinked? Was it overridden? But as weird and tangled as FontConfig can get, there is a way to fix your problem. fontconfig-penultimate on GitHub has conf files that aren't included by default on most distributions other than Ubuntu. Even if it's something they don't believe in, it is a core font technology that remains the standard on non-HiDPI displays. Apple ceased using it because they have total control of the path from font>OS>hardware. You will find plenty of complaints of Mac owners who complain about fonts on their external monitor since AA was removed from the OS.

Hope this was valuable, and that something can be figured out.

OK but what you're asking for is not possible to do downstream. GTK 4 removed support for rgba antialiasing altogether and there are no plans to bring it back. That's not something we can change downstream by tweaking a config option. You'd need to do real upstream work to bring it back.

Grayscale antialiasing is still supported and default.

It'd probably be best to keep this issue focused on hinting vs. subpixel positioning, since antialiasing is an altogether different topic, right?

That said, there needs to be an option to enable it, or GNOME (and by extension Fedora), will look objectively worse for most users around the world.

Fedora has never exposed this setting, at least not since GNOME 3.0. rgba antialiasing was a hidden tweak. It's never been exposed to users except via Tweak Tool, which we've never preinstalled.

We had some trouble deciding what to do here, but ultimately agreed to reenable hinting because nobody is opposed to hinting.

Action: Michael to figure out how to implement

Metadata Update from @catanzaro:
- Issue untagged with: meeting
- Issue tagged with: pending-action

2 years ago

I've pushed a change to gtk4 dist-git and have a successful scratch build, but it seems koji is having some sort of trouble right now and is not responding when I try to start an official build. Will try again later I guess.

Metadata Update from @catanzaro:
- Issue untagged with: pending-action
- Issue tagged with: testing

2 years ago

This change is targeting F38 and not F37? Presumably it only affects GTK apps that are installed from a package? Flatpaks won't be affected by the change?

This change is targeting F38 and not F37?

No, this change is implemented in F37. Just awaiting testing now.

Presumably it only affects GTK apps that are installed from a package?

Yes.

Flatpaks won't be affected by the change?

Right.

Flatpaks won't be affected by the change?

Right.

Or more precisely, Fedora flatpaks are going to be affected, Flathub flatpaks won't be.

No, this change is implemented in F37. Just awaiting testing now.

Did this happen, @catanzaro ?

Yes, let's close this. The change is implemented.

Note that as a side effect, mnemonic underline indicators are now broken in all GTK 4 apps, https://gitlab.gnome.org/GNOME/gtk/-/issues/4818

Metadata Update from @catanzaro:
- Issue untagged with: testing
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

OK but what you're asking for is not possible to do downstream. GTK 4 removed support for rgba antialiasing altogether and there are no plans to bring it back. That's not something we can change downstream by tweaking a config option. You'd need to do real upstream work to bring it back.

Grayscale antialiasing is still supported and default.

It'd probably be best to keep this issue focused on hinting vs. subpixel positioning, since antialiasing is an altogether different topic, right?

That said, there needs to be an option to enable it, or GNOME (and by extension Fedora), will look objectively worse for most users around the world.

Fedora has never exposed this setting, at least not since GNOME 3.0. rgba antialiasing was a hidden tweak. It's never been exposed to users except via Tweak Tool, which we've never preinstalled.

I normally wouldn't reply to a closed topic, and not sure if you'll be notified regardless, but I wanted to address your last paragraph. By that logic, hinting and font selection have never been exposed either. I bring it up not to be combative, but as an example of why some upstream decisions are perceived in a negative way. Discarding rgba for being in tweak tool, in a thread about another setting found in tweak tool, leaves the reader to fill in the logic gaps with other, possibly incorrect motivations.

I have no illusions about my abilities compared to yours or anyone upstream/downstream. I've helped with some theming stuff and laptop compatibility issues, but that's it. I just repeatedly see this kind of disconnect between what's being said and the full, possibly nebulous truth of things. Like when I've been told that Ubuntu's fontconfig doesn't do anything you can't do via GUI on other distros. Except that unless rgba is default with symlink to match, it will not apply to QT apps when set in tweaks tool, and vice-versa for KDE.

Someone much more qualified saying flatly, "It makes no difference," or giving a reason for rgba to be excluded that would also exclude changing font, mouse acceleration, etc, is disheartening. Rgba will mess up non-rgb displays if default. That's all you'd need to justify Fedora's defaults. But the logic of your last paragraph suggests that it would be fine if any other font but Cantarell broke the UI, because that's a 3rd party tweak. You obviously don't think that, so it adds unnecessary friction to the discussion.

Log in to comment on this ticket.

Metadata
Attachments 2