Closed Bug 1624988 Opened 4 months ago Closed 3 months ago

The combination of CSS filters blur & drop-shadow disappear when a new video frame is rendered

Categories

(Core :: Graphics: WebRender, defect, P3)

76 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla77
Tracking Status
firefox-esr68 --- unaffected
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- verified
firefox78 --- unaffected

People

(Reporter: wessel_kroos, Assigned: gw)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36

Steps to reproduce:

Go to: https://codepen.io/wesselkroos/pen/KKpGReq
You can see the red squire's drop-shadow flickering when he meets the canvas blur after ~5 animations.

Actual results:

The red square's drop-shadow is not rendered where the blur and the drop-shadow overlap each other when a new video frame is rendered and the drop-shadow filter has already been rendered in a previous animation frame.

There is a similar issue in Chromium. I've reported it here: https://bugs.chromium.org/p/chromium/issues/detail?id=1064390

Expected results:

The red square's css filter drop-shadow should still be overlapping the canvas's css filter blur.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Reverting automatic component assignment as I don't think this is a media issue. My guess would be that it's related to CSS, or rendering, but will leave it for manual triage as I'm not certain.

Component: Audio/Video: Playback → Untriaged
Product: Core → Firefox

I can reproduce if WebRender ON.

Component: Untriaged → Graphics: WebRender
Product: Firefox → Core
Has Regression Range: --- → yes
Has STR: --- → yes
Regressed by: 1599965
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(gwatson)
Assignee: nobody → gwatson
Flags: needinfo?(gwatson)

The priority flag is not set for this bug.
:jbonisteel, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jbonisteel)
Blocks: wr-76
Flags: needinfo?(jbonisteel)
Priority: -- → P3

Glenn, are you still looking at this?

Flags: needinfo?(gwatson)

I've been focused on the hd4600 work, but yea, I'll take a look at this next week.

Flags: needinfo?(gwatson)

The issue is that drop shadow primitives don't correctly inflate their local rectangle for primitive dependency calculations.

I could make a band-aid fix this this that fixes the simple case (where there's just a blur radius, and no offset), but that won't always work correctly in cases where the drop-shadow has an offset (or more than one drop-shadow on a single primitive).

Unfortunately, the code that deals with inflation of blur and drop-shadow primitives is a bit of a mess, which complicates fixing this properly. I'm going to see if I can tidy this up a bit in a way that will fix this and make the code more maintainable / correct for these cases.

Depends on: 1631687

Include the inflation factor from all drop-shadow filters when
calculating the overall inflation factor for a surface.

This doesn't fix cases with large offsets, which is a larger amount
of work to fix, but it fixes the common case and the referenced
case in this bug.

Pushed by gwatson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f75deee57611
Improve inflation factor calculation for drop-shadows. r=kvark

I had updated and done a try with a fix for that android fuzziness, but had forgotten to push the updated patch to phabricator. I've done that now, so hopefully it should pass this time.

Flags: needinfo?(gwatson)
Pushed by gwatson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c4f20b2600e1
Improve inflation factor calculation for drop-shadows. r=kvark
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

I managed to reproduce the issue using an older version of Nightly 76.0a1 on Windows 10 x64.
I retested using Nightly 77.0a1 and latest Nightly 78.0a1 on Windows 10 x64. The issue is not reproducing anymore.

Status: RESOLVED → VERIFIED

Thanks for the fix Glenn! I've verified the fix in Nightly 78 as well.

You need to log in before you can comment on or make changes to this bug.