Closed Bug 1757201 Opened 2 years ago Closed 2 years ago

invalidation bug with text-shadows + mix-blend-mode

Categories

(Core :: Graphics: WebRender, defect)

x86_64
Windows 10
defect

Tracking

()

RESOLVED FIXED
99 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox97 --- unaffected
firefox98 --- unaffected
firefox99 + verified

People

(Reporter: Gankra, Assigned: gw)

References

(Regression)

Details

(Keywords: regression)

Attachments

(5 files)

Attached file about:support

STR:

alternative:

expected result:

chromatic abberation-y "Faultlore" text should render properly (colored fringing but coherent)

actual result:

chromatic abberation-y "Faultlore" text has huge random blocks of solid red, is clearly being invalidated wrong


I incidentally already have a mostly reduced example of this at https://gankra.github.io/blah/rustblog/before.html.

The problematic input is:

  • 3 nested copies of the text "Faultlore"
  • text set to transparent
  • each textrun has a different color shadow at a different offset (cyan, magenta, yellow)
  • the textruns are merged with mix-blend-mode: darken

The net effect of this is that you get colorful printer-style bleeding around the edges but where the shadows all overlap you get a fairly clean black copy of the text. This is obviously very evil and not terribly surprising that it breaks webrender.

This appears to be a recent regression. I developed and tested this abomination in firefox nightly on this machine only a few days ago, and resizing the window never corrupted the result during that time.

not 100% sure this is invalidation after messing around with window resizing, but these corruption patterns are so weird that there's something clearly very messed up happening.

if it glitches for you if you pinch-zoom, might be a dupe of bug 1756929

See Also: → 1756929
Assignee: nobody → gwatson
Attached file g1.html

A slightly more reduced test case

Has Regression Range: irrelevant → yes

Setting gfx.webrender.debug.force-picture-invalidation works around it for me, looks to be an issue where we don't invalidate either the correct bounding rects, or deeply enough in the surface hierarchy.

Hmm, looks like there are two issues - setting gfx.webrender.debug.force-picture-invalidation fixes one problem, but there's still glitches during resize which look like a different bug.

possible to get a try build for testing?

(In reply to Mayank Bansal from comment #11)

possible to get a try build for testing?

Yup, you beat me to it - was just about it post it (artifacts not available yet but should be soon).

https://treeherder.mozilla.org/jobs?repo=try&revision=422897f59ab4bb22f71da5d2c68426ebb86ab467

Pushed by gwatson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7aaefe97188d
Fix mix-blend mode on parent surfaces with snapping enabled r=gfx-reviewers,lsalzman
Backout by nerli@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d6aabaf771d4
Backed out changeset 7aaefe97188d for causing bustage in mix-blend-layers.yaml CLOSED TREE

Added a bit of fuzziness to account for android hardware rendering and re-pushed.

Flags: needinfo?(gwatson)
Pushed by gwatson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/157f7165d8d9
Fix mix-blend mode on parent surfaces with snapping enabled r=gfx-reviewers,lsalzman
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 99 Branch
Blocks: 1756929
Blocks: 1757261
See Also: 1756929
Flags: qe-verify+

I was able to reproduce the issue on Win10x64 using build 99.0a1(20220225104705), when scrolling up/down text appears Red.
Verified as fixed on Win10x64 / Ubuntu 20.4 / Mac 10.13 using builds: 99.0b4(20220315185755) and 100.0a1 (20220316095231).

Flags: qe-verify+

(In reply to Andra Esanu from comment #19)

(In reply to Noemi Erli[:noemi_erli] from comment #18)

https://hg.mozilla.org/mozilla-central/rev/157f7165d8d9

== Change summary for alert #33487 (as of Mon, 07 Mar 2022 11:27:48 GMT) ==

Improvements:

Ratio Test Platform Options Absolute values (old vs new)
149% motionmark_webgl 3DGraphics-WebGL linux1804-64-shippable-qr e10s fission stylo webrender-sw 4.09 -> 10.18
143% motionmark_webgl 3DGraphics-WebGL linux1804-64-shippable-qr e10s fission stylo webrender 4.26 -> 10.34
40% motionmark_webgl 3DGraphics-WebGL linux1804-64-shippable-qr e10s fission stylo webrender 7.10 -> 9.93
21% glvideo Mean tick time across 100 ticks: linux1804-64-shippable-qr e10s fission stylo webrender 21.84 -> 17.17
20% glvideo Mean tick time across 100 ticks: linux1804-64-shippable-qr e10s fission stylo webrender-sw 21.54 -> 17.14

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=33487

:jgilbert there are some significant improvements associated with this change, can you confirm these are expected/genuine?

Flags: needinfo?(jgilbert)

@gw these seem high, or is this a kind of small-change-big-effect we expect here?

Flags: needinfo?(jgilbert) → needinfo?(gwatson)

The patch in this bug should only affect mix-blend-mode elements (and I wouldn't expect a major performance difference), which I doubt the above tests have? So it seems likely to be unrelated to this bug, perhaps an incorrect attribution?

Flags: needinfo?(gwatson)

Andra, could you review the alert to see if this is the correct bug to associate with this improvement?

Flags: needinfo?(aesanu)

Thank you for this. It seems the culprit was a bit earlier, I've linked the alert to bug 1638466.

Flags: needinfo?(aesanu)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: