1815700 - COLRv1 font renders incorrectly at small-medium text sizes

Status: VERIFIED FIXED

(Core :: Graphics: Text, defect)

Description

[harry.dalton]

Attachment: ZIP containing a reproduction page for the issue, including an affected COLRv1 test font

Steps to reproduce:

I can reproduce by following these steps:

1. Open "reproduce.html" from the attached files in the browser.

2. Two glyphs from a COLRv1 font are displayed at a range of text sizes.

Actual results:

The first glyph is rendered incorrectly at text sizes <34px, and the second glyph is rendered incorrectly at text sizes <50px. At these smaller sizes, the font's colouring is no longer correct, and significant rendering artefacts are visible.

Expected results:

The glyphs should render correctly at every text size.

Environments tested:

The font displays correctly in:

• Chrome 109.0.5414.120, on Windows 10 (Version 21H2).

The font displays incorrectly in:

• Firefox 109.0.1, on Windows 10 (Version 21H2).

Fonts tested:

The attached reproducing page is based on Google Fonts' COLRv1 test font[1], but the problem can also be reproduced with Dalton Maag's Shader Glitch[2].

[1] https://github.com/googlefonts/color-fonts/blob/43fd84/fonts/test_glyphs-glyf_colr_1.ttf
[2] https://www.daltonmaag.com/library/shader-color > Scroll to test panel > Select 'Shader Glitch' > Set font size to 30

Comment 1

[harry.dalton]

Attachment: Screenshot demonstrating the issue, showing correct and incorrect behaviour

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Brad Werth [:bradwerth] (out until March 10)]

Jonathan, would you please take a look?

Comment 4

[Jonathan Kew [:jfkthame]]

The testcase renders fine at all sizes on macOS, which leads me to suspect this is a Windows-specific glitch; I'll try reproducing on my Windows machine later. It may be that the glyph outlines start failing below a certain size in DirectWrite.

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: screenshot from Nightly on Win10

This does not reproduce for me on Win10 (21H2) using either Firefox release (109.0.1) or Nightly (111.0a1); the glyphs render OK at all sizes in the testcase.

As such, I suspect it may be a DirectWrite issue that's related to a specific graphics driver, or maybe manifests with particular system font rendering settings?

Comment 6

[harry.dalton]

Attachment: Screenshot from Release on Arch Linux (reproduces)

Hi Jonathan – thank you for looking into this.

We have a new lead! Since your last message, we have managed to reliably reproduce the issue in Firefox release (109.0.1) on Linux (Arch Linux, kernel 5.18.10).

This time we tested with a new machine that is independent of our Windows environment, and which does not share the same configuration. Are there any further details we can provide that would help in narrowing down which environments/code paths are affected?

Comment 7

[Jonathan Kew [:jfkthame]]

Interesting - thanks for that. I don't have an Arch Linux system on hand, but will try with my Ubuntu machine and see if I can repro there. (I wouldn't be surprised if it turns out to depend on the FreeType hinting mode in use, or something like that...)

Comment 8

[Jonathan Kew [:jfkthame]]

OK, this does reproduce for me on Ubuntu. I'll see if I can get any more insight into what's going on.

Comment 9

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

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 10

[Jonathan Kew [:jfkthame]]

This is really puzzling. It seems to be only glyphs using the PaintComposite operation that fail, and only when they're below a certain size threshold. If I patch out the compositing aspect so that PaintComposite just renders the backdrop and foreground components directly, they work fine (but of course don't combine as intended).

My first idea was that somehow the temporary Skia surface we use for the compositing is buggy and starts to misrender when it has very small dimensions. But forcing a generous minimum size for that surface (rather than fitting it to the bounds of what we actually need to paint) doesn't make any difference, so it's something more subtle that's going on.

Comment 11

[Jonathan Kew [:jfkthame]]

I think we must be running into a bug in the Moz2d or Skia functions being used to handle the PaintComposite operation, though I don't understand exactly where at this point. However, I do have a workaround that appears to fix the problem on my Linux system, at least.

Harry, if you're able to test an experimental build and confirm whether it solves the problem for you, that would be really helpful.

The Linux build is at: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/EZh5rqquRIyNns4AMJIk6Q/runs/0/artifacts/public/build/target.tar.bz2
And a Windows build: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/BzoBShMvRXyr0tKzil_zhA/runs/0/artifacts/public/build/target.zip

In either case, it should work to just expand the archive and then launch the Firefox executable from within the resulting directory; it's not necessary to install over the top of your normal Firefox version. (But be sure to quit any other version of Firefox first, to avoid possible confusion - otherwise there's a tendency to just open a new window in the already-running application instead of running the new version.)

Comment 12

[harry.dalton]

Thanks for the speedy investigation, Jonathan!

On Windows 10, I was able to confirm that the artefacts were no longer immediately visible for the fonts I referenced in the initial bug report, however, a crash prevented me from checking in more depth. It can be reproduced by:

1. Navigating to https://roettsch.es/var_colrv1.html
2. Dragging the "SKXA" slider all the way to the left

...after which the tab crashes. If this does not reproduce for you, are there any log/dump files it would be helpful to attach?

Comment 13

[harry.dalton]

Attachment: Artefact is influenced by factors other than size

As an aside: when testing with Firefox Release, I observed factors other than size influencing whether the artefacts were visible, in case this is helpful in pinpointing the core issue with the drawing functions.

e.g. In the included GIF, the left-most glyph displays the artefact at much larger sizes when the SCSX axis is negative.

Comment 14

[Jonathan Kew [:jfkthame]]

Thanks so much for the prompt testing & report! I was able to reproduce the crash, and have started a new try build with a fix: https://treeherder.mozilla.org/jobs?repo=try&revision=06880d41b364e76dc78182d8d0350b2f8d5bca07

I'll add links to the builds once they're available for download.

[edit to add:]
Linux: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Y-MgqZ9zRAuahSg9ePW7yA/runs/0/artifacts/public/build/target.tar.bz2
Windows: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/J1KK_z48QkCOE8Bd0RYVvg/runs/0/artifacts/public/build/target.zip

Comment 15

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1815700 - Render COLRv1 PaintComposite operations without using PushLayerWithBlend, as it seems to be unreliable in some cases. r=#gfx-reviewers

This seems tricky to test in CI as it doesn't reproduce consistently
(originally reported on Windows, but I haven't been able to reproduce it
there at all; but successfully repro'd and tested locally on Linux).

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/791e35ecfa03
Render COLRv1 PaintComposite operations without using PushLayerWithBlend, as it seems to be unreliable in some cases. r=gfx-reviewers,lsalzman

Comment 17

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/791e35ecfa03

Comment 18

[harry.dalton]

Attachment: Screenshot from experimental build Win10 (fixed)

All good news this time! I am happy to report that the latest experimental build has fixed the bug for me with the reported fonts on both Windows 10 (see attached) and Arch Linux.

Thanks again Jonathan for taking a deep dive on this; the fix is much appreciated : )

Comment 19

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Reproduced the issue with Firefox 109.0.1 on Windows 10x64 and Ubuntu 20.04 by using the attached test case from comment 0 and comment 13.
I can no longer reproduce the issues with Firefox 112.0b9 on Windows 10x64, macOS 12, and Ubuntu 20.04. The fonts are displayed correctly for the test case attached in comment 0 and the glyphs are no longer visible for the scenario presented in comment 13.