1873708 - Canvas fillText+Filter - Over-Clipping on mixed ASCII+Emojis

Status: VERIFIED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Thomas Brierley]

Attachment: firefox-canvas-filltext-filter-bug.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0

Steps to reproduce:

Set up a canvas and 2d context. Add any filter to the context, use fillText with a string containing a combination of ASCII and unicode emojis. Ensure the leftmost and rightmost characters are emojis to make the incorrect clipping more obvious.

Actual results:

The rendered text is clipped to a bounding box containing only the ASCII characters. The emoji characters will still be rendered but clipped on both the x and y.

Expected results:

The full text should be visible.

Note: This does not occur if all of the characters are emojis. It also doesn't seem to generalise to any non-ASCII code point, and is not even specific to UTF-16 surrogate pairs some of which can be used without triggering this bug. It seems to be specific to emoji characters (although I have not tested all of them), perhaps because they are not simple vectors outlines.

Comment 1

[Thomas Brierley]

Attachment: firefox-canvas-filltext-filter-bug.html (FIXED UNICODE)

Upload mangled the unicode, this one has unicode escapes.

Comment 2

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

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

Comment 3

[Erich Gubler [:ErichDonGubler] (he/him)]

Confirmed on my M1 Mac. Requesting a Pernosco session, in case it helps. NI'ing triage owner.

Comment 4

[Jason Kratzer [:jkratzer]]

Erich, unfortunately bugmon can only be used to record pernosco sessions for bugs that trigger a crash or fatal assertion.

Comment 5

[Jonathan Kew [:jfkthame]]

On macOS, there's a less severe form of this issue: I'm seeing the filtered emoji glyphs being clipped at the baseline, but at least they're not clipped at the top or sides.

In both cases, I assume the cause is that our attempt to get glyph bounds (as a basis for the size of the surface used during the filtering operation) is failing for bitmap glyphs.

Comment 6

[Jonathan Kew [:jfkthame]]

(In reply to Jonathan Kew [:jfkthame] from comment #5)

In both cases, I assume the cause is that our attempt to get glyph bounds (as a basis for the size of the surface used during the filtering operation) is failing for bitmap glyphs.

Huh, in the Linux case it's the Twemoji Mozilla font that's not getting proper bounds. I guess that's because it doesn't have fallback monochrome glyphs at the nominal glyph IDs; it only has the color layers, and FreeType isn't considering those when we retrieve the bounds in gfxFT2FontBase::GetFTGlyphExtents.

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1873708 - patch 1 - Synthesize fallback glyph extents for color glyphs if FreeType returned empty bounds, to avoid clipped rendering. r=#gfx-reviewers

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1873708 - patch 2 - Try to avoid clipping emoji glyphs on macOS when applying canvas filters. r=#gfx-reviewers

Comment 9

[Thomas Brierley]

Nice work, that was quick!

Comment 10

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1873708 - Add a simple reftest based on the reporter's example. r=#gfx-reviewers

Depends on D198279

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c6b21b2db104
patch 1 - Synthesize fallback glyph extents for color glyphs if FreeType returned empty bounds, to avoid clipped rendering. r=gfx-reviewers,aosmond
https://hg.mozilla.org/integration/autoland/rev/0dc21611ff97
patch 2 - Try to avoid clipping emoji glyphs on macOS when applying canvas filters. r=gfx-reviewers,aosmond
https://hg.mozilla.org/integration/autoland/rev/387701b0f788
Add a simple reftest based on the reporter's example. r=gfx-reviewers,jrmuizel

Comment 12

[Cristina Horotan [:chorotan]]

Backed out 3 changesets (Bug 1873708) for causing reftest failures at color-opacity-rtl-2.html

Backout: https://hg.mozilla.org/integration/autoland/rev/8a920551ed614edc519c5ae3b6486018fff08da5

Failure push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=387701b0f78814c3a2b1e5ba52c5c73a06af5a43

Failure log: https://treeherder.mozilla.org/logviewer?job_id=443156117&repo=autoland&lineNumber=4474

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f7d8b68a1368
patch 1 - Synthesize fallback glyph extents for color glyphs if FreeType returned empty bounds, to avoid clipped rendering. r=gfx-reviewers,aosmond
https://hg.mozilla.org/integration/autoland/rev/8749d9a52c79
patch 2 - Try to avoid clipping emoji glyphs on macOS when applying canvas filters. r=gfx-reviewers,aosmond
https://hg.mozilla.org/integration/autoland/rev/abab19c548b5
Add a simple reftest based on the reporter's example. r=gfx-reviewers,jrmuizel

Comment 14

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/f7d8b68a1368
https://hg.mozilla.org/mozilla-central/rev/8749d9a52c79
https://hg.mozilla.org/mozilla-central/rev/abab19c548b5

Comment 16

[Catalin Sasca, Desktop Test Engineering [:csasca]]

I was able to reproduce the issue on Firefox 123.0a1 (2024-01-08) on macOS 14.3.1 by using the provided file in Comment 1.

The issue is fixed on Firefox 123.0b9 and Firefox 124.0a1 (2024-02-11). Tests were performed on macOS 14.3.1, Windows 11 and Ubuntu 22.04.