"dot" character is improperly rendered on Ubuntu
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox100 | --- | unaffected |
firefox101 | --- | unaffected |
firefox102 | --- | verified |
firefox103 | --- | verified |
People
(Reporter: danibodea, Assigned: lsalzman)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
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
- Launch browser.
- Load https://media.pragprog.com/titles/ktuk/excerpts.pdf
- 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•2 years ago
|
||
: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•2 years ago
|
||
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•2 years ago
|
||
:lsalzman, since you are the author of the regressor, bug 1770088, could you take a look?
For more information, please visit auto_nag documentation.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 4•2 years ago
|
||
Because DrawTargetWebgl uses subpixel quantization, we need to pad glyph textures
beyond just the 1 pixel required for anti-aliasing.
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Pushed by lsalzman@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6ce3dec607ab Add more glyph padding in DrawTargetWebgl. r=aosmond,gfx-reviewers
Comment 7•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Comment 8•2 years ago
|
||
Verified as fixed on Ubuntu 20.04 x64.
Description
•