1770706 - "dot" character is improperly rendered on Ubuntu

Status: VERIFIED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Daniel Bodea [:danibodea]]

Attachment: demo - comparison - left chrome - right nightly

Note

• When the user loads a specific PDF and scrolls through it, he will notice that the dot character is improperly rendered.

Affected versions

• Nightly v102.0a1

Affected platforms

• Ubuntu 22 (both wayland and xwayland)

Steps to reproduce

1. Launch browser.
2. Load https://media.pragprog.com/titles/ktuk/excerpts.pdf
3. Scroll to find some dot characters.

Expected result

• They are properly displayed.

Actual result

• They are improperly displayed.

Regression range

• Very recent regression:
  11:05.82 INFO: Last good revision: 6ff77198e6fdbdd8bc60ca2ba0b22e4669ce44b9
  11:05.82 INFO: First bad revision: 59527af3a10bb95f0e7f019d15f62f7e45e722af
  11:05.82 INFO: Pushlog:
  https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6ff77198e6fdbdd8bc60ca2ba0b22e4669ce44b9&tochange=59527af3a10bb95f0e7f019d15f62f7e45e722af

Additional notes

• It occurs on both wayland and xwayland so it is not related to the Window Protocol.
• It's most likely to reproduce after zooming out.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:danibodea, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Comment 2

[Jonathan Kew [:jfkthame]]

This doesn't seem to reproduce for me on Ubuntu 20.04. I suspect it's dependent on font hinting/antialiasing settings on the system, as well as possibly the freetype version that's present.

Looking at the screenshot, it seems to be specifically the URWGothicL font that is exhibiting this problem. It's not limited to dots, actually: at the bottom of the screenshot, there are similar glitches in "killall" that appear to affect two of the four "l" glyphs there.

The screenshot also shows erratic rendering of the main body text (Bookman) font, where some glyphs are raised or lowered by a pixel compared to the surrounding text. Within any given line, the behavior seems to be consistent (regarding which glyphs are mispositioned), but different lines show different sets of affected glyphs. I suspect this is dependent on the precise (fractional-pixel) vertical position of the lines, and reflects an lack of hinting (and perhaps a freetype configuration that also disables its auto-hinter).

Anyhow, this is definitely on the Graphics side more than Layout: it's poor font rasterization, and (in the case of the URWGothicL font) looks like maybe a glyph cache or blitting failure of some kind.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

:lsalzman, since you are the author of the regressor, bug 1770088, could you take a look?
For more information, please visit auto_nag documentation.

Comment 4

[Lee Salzman [:lsalzman]]

Attachment: Bug 1770706 - Add more glyph padding in DrawTargetWebgl. r?aosmond

Because DrawTargetWebgl uses subpixel quantization, we need to pad glyph textures
beyond just the 1 pixel required for anti-aliasing.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6ce3dec607ab
Add more glyph padding in DrawTargetWebgl. r=aosmond,gfx-reviewers

Comment 7

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/6ce3dec607ab

Comment 8

[Hani Yacoub, Desktop QA]

Verified as fixed on Ubuntu 20.04 x64.