Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blurry fonts due to lack of anti-aliasing options #288

Open
ibrahimrahman opened this issue Aug 26, 2021 · 11 comments · May be fixed by #291
Open

Blurry fonts due to lack of anti-aliasing options #288

ibrahimrahman opened this issue Aug 26, 2021 · 11 comments · May be fixed by #291
Labels
Needs Design Waiting on input or designs from the UX team Status: Confirmed Reproducible or confirmed by someone other than the reporter

Comments

@ibrahimrahman
Copy link

Problem

On my low resolution (1366x786) and low quality lcd display, fonts with grayscale anti-aliasing look blurry. However setting antialiasing to rgba using dconf-editor makes them smoother and more readable.

Proposal

Allow changing anti-aliasing type from the appearance plug. There have been some complaints about blurry fonts since the switch to inter. I thought it was the same for me but it turned out to be related to anti-aliasing. Perhaps this would help such users as well

@cassidyjames
Copy link
Contributor

I think I agree that this is a hardware compatibility issue and would be worth shipping. We’ve heard very mixed reports including lots of positive and lots of negative about the switch to grayscale, so perhaps it’s worth shipping the option.

@cassidyjames cassidyjames added this to To do in OS 6.1 via automation Aug 27, 2021
@danirabbit danirabbit moved this from To do to 6.0.2 in OS 6.1 Sep 1, 2021
@kdwk
Copy link

kdwk commented Sep 2, 2021

My concern is that a lot of users might not know what anti-aliasing is and no realize how it relates to text smoothness and readability. Therefore, I don’t think simply presenting anti-aliasing options as a simple list is a good idea. Perhaps we could do graphical representations in the Settings UI of different anti-aliasing methods so users can see for themselves which one is better before choosing?

@ibrahimrahman
Copy link
Author

The thing with anti-aliasing is that it makes a very slight difference that can have a much larger impact. Changing it on some displays might make a larger difference than on others. I imagine it would be quite difficult to graphically represent what difference changing it would make. Especially if there are graphics explaining how the options vary, while the difference in actual readability after applying is not evident right away.

IMO, a well defined list should suffice. If need be, a statement about what anti-aliasing is should make things a lot clear. Those who need to change it will know what to do, those who wish to learn what it is, will have ways to learn about it, and for those for whom it doesn't matter, it won't make a difference.

Here's how gnome does it:

Screenshot from 2021-09-03 01-40-15

Apart from this, it also offers an option to change the hinting setting

@jhaygood86
Copy link

Anecdotal evidence for a need for such an option, or changing the default (either across the board or via heuristics):

I have a fairly high quality LoDPI monitor (15.6" 1080p, but its a high refresh rate Alienware display built into an Alienware m15), and Grayscale looks very blurry, while RGBA is very readable.

@davidmhewitt
Copy link
Member

davidmhewitt commented Sep 3, 2021

I wonder how possible it is to convince GTK to render the same string using the three different aliasing options (on screen at the same time), so you can do a "which of these looks better?" thing like what Microsoft used to (maybe still does) with cleartype

@cassidyjames
Copy link
Contributor

@davidmhewitt that could be interesting! We could also just embed pre-rendered images (e.g. from a screenshot) with the given settings, yeah?

@davidmhewitt
Copy link
Member

Uh, possibly, but they'd need to be pixel aligned because it's all about the "sub-pixel" stuff, so they'd end up being different sized fonts on different resolution displays I guess.

@cassidyjames
Copy link
Contributor

Right, we'd need to ensure pixel perfect screenshots (and 1× and 2× variants) but I think showing e.g. a heading and some copy in a pixel-perfect screenshot would work… right? When I change the settings and take a screenshot here, I can see the aliasing itself in the screenshot, and that should be identical across displays as long as it's displayed at 100% at the correct scaling factor.

@davidmhewitt
Copy link
Member

Yup, I guess. But a cursory check of the docs seems to suggest it's possible to do for real on a label:

https://valadoc.org/gtk+-3.0/Gtk.Widget.set_font_options.html

Just need to figure out which Pango aliasing settings map to the ones available in gsettings.

@jhaygood86
Copy link

jhaygood86 commented Sep 4, 2021

Looking into this:

gnome-settings-daemon is storing this in xsettings (which makes sense)

see: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/plugins/xsettings/gsd-xsettings-manager.c

none:
antialias = 0

grayscale:
antialias = 1
rgba = none

rgba:
antialias = 1
rgba = [leaves previous setting] (which defaults to rgb)

Note: the rgba setting can be one of rgb, bgr, vrgb, and vbgr, I'm assuming to handle different subpixel orientations.

GTK then transforms them to Cairo using this:

see: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gtk/gtksettings.c

antialias = 0 -> CAIRO_ANTIALIAS_NONE
antialias = 1 & rgba is not set -> CAIRO_ANTIALIAS_GRAY
antialias = 1 & rgba is set -> CAIRO_ANTIALIAS_SUBPIXEL

And the settings do work :)

Screenshot from 2021-09-03 22-07-37

@jhaygood86
Copy link

I added an initial pull request to fix this in #291

@danirabbit danirabbit moved this from 6.0.2 to To do in OS 6.1 Sep 22, 2021
@danirabbit danirabbit moved this from To do to In progress in OS 6.1 Nov 22, 2021
@danirabbit danirabbit removed this from In progress in OS 6.1 Nov 22, 2021
@lenemter lenemter added Status: Confirmed Reproducible or confirmed by someone other than the reporter Needs Design Waiting on input or designs from the UX team labels Jul 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Design Waiting on input or designs from the UX team Status: Confirmed Reproducible or confirmed by someone other than the reporter
Projects
None yet
6 participants