1978440 - [wayland] pixel-snapped text decoration lines like line-through, overline, underline are hard to see with 125% system scale, since they're antialiased across two much-fainter pixel rows

Status: NEW

(Core :: Widget: Gtk, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Load attached testcase (which has 3 character-widths of overline/strikethrough/underline, at various y-offsets).
2. Look at the relative darknesses of the lines.
3. (optional): view with a zoom-overlay-tool that shows individual device-pixels; or take a screenshot and paste it into an image editor, and zoom in to see the individual pixels.

EXPECTED RESULTS:

• Lines should not be antialiased.
• Visually, they should look like they're all the same darkness.

ACTUAL RESULTS:
Some of the lines are antialiased across two pixel-rows, both of which look quite faint. These lines look much fainter and are harder to see.

NOTES:
This makes a meaningful difference on Bugzilla which uses a line-through (aka strikethrough) to indicate whether a bug is closed or not. In many cases recently I've mistakenly thought Bugzilla was missing this decoration, only because the decoration was antialiased and hence too faint to notice.

I'm using Ubuntu 25.04 with 125% HiDPI/pixel-scaling in my system display settings (which might also be a relevant factor for triggering this).

[EDIT: Originally I said I had 200% HiDPI, but I just double-checked and it's actually 125% -- but we report it as window.devicePixelRatio of 2 which is interesting... See comment 5]

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot of Firefox Nightly (top) vs Chrome (bottom)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: same screenshot, scaled up 4x to make it easier to see the antialiasing

Here's that screenshot scaled up 4x.

This makes it easier to see where Firefox is doing antialiasing here. Counting from the left (with the first stack of 3 lines being #1):

overline:

• divs # 4, 5, 6, 7, 8 are smeared across two faint pixel-rows, both of which are more white than black.

line-through & underline:

• divs #9,10,11,12,13 are smeared across two faint pixel-rows, both of which are more white than black.

Additionally, some of the lines are just a fainter shade of gray but still only 1px wide, for no obvious reason. E.g. the first three line-through lines are like that, #808080 which is a pretty middling shade of gray.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot of how this affects Bugzilla

Here's a screenshot of how this looks in-practice on Bugzilla. This is a screenshot of bug 1860328

All of the bug numbers in this screenshot have a line-through, except for the leftmost "Regression" bug. But at least on my display, I have a hard time being sure whether there's a line-through or not, particularly for the top two (in the "Blocks:" section).

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: scaled-up-and-cropped version of Bugzilla screenshot

Here's a scaled up version of that Bugzilla screenshot, to make it easier to see that the line-through is antialiased & much fainter than the surrounding text for the two bugs in the "Blocks" section.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

I'm using Ubuntu 25.04 with 200% HiDPI/pixel-scaling in my system display settings (which might also be a relevant factor for triggering this).

Sorry, it turns out I actually had 125% pixel-scaling configured in Ubuntu settings -- but strangely that still shows up in Firefox as a window.devicePixelRatio of 2. 125%, 150%, and 200% all show up as giving Firefox a web-exposed window.devicePixelRatio of 2, whereas Chrome reports 1.25 and 1.5 for 125% and 150%.

Maybe that discrepancy is part of the problem here...

Comment 6

[Emilio Cobos Álvarez (:emilio)]

(In reply to Daniel Holbert [:dholbert] from comment #5)

Maybe that discrepancy is part of the problem here...

That's expected. You should see the right scale factor with widget.gtk.fractional-scale.enabled (if your Mutter version supports it).

Comment 7

[Daniel Holbert [:dholbert]]

Ah thanks - s/gtk/wayland/ I think. Looks like this is the pref: https://searchfox.org/mozilla-central/rev/146c8d8d1f3cf15be3c263808f9674a97752c41a/modules/libpref/init/StaticPrefList.yaml#18658

- name: widget.wayland.fractional-scale.enabled

Comment 8

[Daniel Holbert [:dholbert]]

Aha! That pref is important here -- toggling it to true seems to fix the issue. The bug only reproduces when that pref is at its default value of false and my system is set to a fractional scale value like 125% (or 150%[i]).

In particular, when using a fractional system scale value: when I toggle that pref (widget.wayland.fractional-scale.enabled) to true and restart Firefox, then the attached testcase renders as-expected, with 1-device-pixel-thick solid-black lines, even if I've got a fractional scale value.

(Also: if I leave that pref at its default level and I set my system scale level to a non-fractional scale like 200%, then the attached testcase also renders as-expected, with 1-device-pixel-thick solid-black lines.)

[i] 150% is affected but not-as-bad as 125%. With a system scale level of 150%, the dashes all render the same, with a dark stroke for the top row of pixels and a lighter stroke for the lower row of pixels.

Comment 9

[Daniel Holbert [:dholbert]]

Given that, I suspect this affects all pixel-snapped lines (not just text decoration lines), and it's specific to the Wayland backend. Hence, reclassified as Widget:Gtk and tied to the wayland metabug.

I suspect this should also be tied to the gtk-fractional-scale metabug (bug 1837374), but I'll mark this as depending-on that metabug since this is fixed by that feature (rather than being a bug in that feature, which I think is what all of the bugs that block that metabug are about).