1404218 - [APZ] css filters break rendering of fixed background-image

Status: NEW

(Core :: Panning and Zooming, defect, P3)

Description

[C. Martin]

Attachment: bg-fixed-plus-blur.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170926190823

Steps to reproduce:

Apply CSS filter blur() on a div with a fixed background-image:
https://kunden.cmcm.info/moz-bug-bg-fixed-css-filters/bg-fixed-plus-blur.html
Testcase: first div without filter, second div with filter



Actual results:

The background image in the blurred div is not rendered at all.


Expected results:

The blurred div should be rendered with a background image.
Works in Chrome and Edge.

Comment 1

[Alice0775 White]

Scroll with mouse wheel : not render, and then mouse hover over scrollbar: eventually render
Scroll with mouse drag scroll thumb : not render, and then mouse up: eventually render

Comment 2

[C. Martin]

Even if it eventually renders, the background never stays fixed but always scrolls with the page.

Comment 3

[Alice0775 White]

Disable APZ seems to fix the problem

Comment 4

[Alice0775 White]

1st regression of bad behavior with mouse wheel :
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=eca3a6b94f7934377b099ddb22ae9c91f340cbfc&tochange=9066ef31441959ae15b83d59395ed34d3ed03c0a

Regressed by : Bug 1192910

@Kartikaya
Your bunch of patch seems to cause the problem, Can you look at this?

Comment 5

[C. Martin]

Re.: status-firefox-esr52: --- → unaffected

I experience the same issues with ESR52 (Windows 7/32bit)

Comment 6

[Kartikaya Gupta (email:[e-mail])]

(In reply to C. Martin from comment #2)
> Even if it eventually renders, the background never stays fixed but always
> scrolls with the page.

Can you clarify what you mean by this? I can reproduce the problem where upon scrolling down, instead of showing the blurred image, it just shows white. And if I click on the page or otherwise do something that triggers a repaint, it shows the blurred image correctly. However at that point if I scroll, it just translates whatever it had painted as the blurred image before, rather than updating the blur to cover what it should. Is that what you meant by "background never stays fixed"? I interpreted "background" as the original, un-blurred image, and that does remain fixed for me.

I tried turning off paint-skipping and while that helps, it doesn't fix the problem entirely - the blur is still "jittery". I guess this is a scenario where we cannot have APZ at all, as we cannot generate the layer with the blur contents ahead of time. Markus, does that seem correct, or am I missing something?

Comment 7

[C. Martin]

>Can you clarify what you mean by this?

Sure. In my demo the background-image has the property "background-attachment: fixed". So upon scrolling the blurred background should be revealed from bottom up but should not move itself while scrolling.

It's probably easiest if you check with Chrome since it renders this correctly.

Or watch this short screen video I just made: https://youtu.be/WoJxKm9J1Ig (first Firefox, then Chrome, then Edge)

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Thanks, that matches what I'm seeing as well.

Comment 9

[Botond Ballo [:botond]]

This sounds like the same underlying issue as bug 1300864, just with a different type of filter.

See bug 1300864 comment 3 for options about what to do.

Comment 10

[Andrew Overholt [:overholt]]

Given comment 9, this seems almost like a dupe of bug 1300864 so I'm setting the flags to be similar.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Botond, now that bug 1300864 is fixed, is there anything else that needs to be done here?

Comment 12

[Botond Ballo [:botond]]

The change made in bug 1300864 helped things significantly, but still not as much as I had hoped. I'd like to make these pages behave better still.

My roadmap for continuing to investigate this issue is:

  1) Check the post-{bug 1300864} behaviour with WebRender.
     This is blocked on bug 1421825.

     If the behaviour with WebRender is good enough, we could
     just decide to wait for WebRender to make things better.

  2) In the behaviour with WebRender is still not good enough,
     or if we decide we don't want to wait for WebRender, we
     should check whether the cause is slow paints, or something
     else.

     In theory, with the fix for bug 1300864 *and* the APZ frame 
     delay (bug 1375949) in place, if we can paint the page
     within the 16 ms frame budget, scrolling should be perfect.

     So, if we are in fact painting within the frame budget,
     and still not scrolling perfectly, it means there's another 
     underlying issue which we need to be diagnosed.

  3) If all else fails, we could consider the second approach
     described in bug 1300864 comment 3: disabling APZ for
     affected scroll frames.

Comment 13

[Firefox Bug Husbandry Bot]

https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals

Comment 14

[Botond Ballo [:botond]]

The image file referenced by the attached testcase no longer resolves. Could you please upload a self-contained testcase (e.g. a zip file containing the page and the image, or a page with the image embedded as a data: URL) so we can continue testing the browser's behaviour on it?

Comment 15

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #12)
> The change made in bug 1300864 helped things significantly, but still not as
> much as I had hoped. I'd like to make these pages behave better still.
> 
> My roadmap for continuing to investigate this issue is:
> 
>   1) Check the post-{bug 1300864} behaviour with WebRender.
>      This is blocked on bug 1421825.
> 
>      If the behaviour with WebRender is good enough, we could
>      just decide to wait for WebRender to make things better.

Kats pointed out in bug 1421825 comment 6 that the problem in that bug is resolved by turning on gfx.webrender.hit-test, so bug 1421825 is no longer a blocker to testing the behaviour with WebRender.

I couldn't test the testcase in this bug (as per previous comment), but I tested the testcase from bug 1300864 and it works great with WebRender. I suspect that's likely to be the case for the testcase in this bug and related bugs (like bug 1418923) as well.

Assuming that's the case (I'll still verify once the testcase here comes online again), my inclination would be to just wait for WebRender to ship to make the behaviour on testcases like this better. I'm open to being convinced otherwise though.

Comment 16

[C. Martin]

Sorry, I restored the image for https://kunden.cmcm.info/moz-bug-bg-fixed-css-filters/bg-fixed-plus-blur.html
I'll also upload the test as a zip file.

Comment 17

[C. Martin]

Attachment: bg-fixed-plus-blur.zip

Complete test case

Comment 18

[Botond Ballo [:botond]]

Thanks!

(In reply to Botond Ballo [:botond] from comment #15)
> I
> tested the testcase from bug 1300864 and it works great with WebRender. I
> suspect that's likely to be the case for the testcase in this bug and
> related bugs (like bug 1418923) as well.

Confirmed that the testcase in this bug works great with WebRender as well.

Comment 19

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #15)
> my inclination would be to just wait for WebRender to ship to
> make the behaviour on testcases like this better. I'm open to being
> convinced otherwise though.

We discussed this during today's gfx team standup, and some people felt it would be good to continue exploring non-WebRender mitigations, as it's going to be a while until WebRender rolls out to all users (on Linux, for example, it depends on hardware acceleration, which we have still not enabled by default).

So, I'm at least going to keep this bug open to explore further mitigations. My next line of investigation will relate to point (2) from comment 12:

>      we
>      should check whether the cause is slow paints, or something
>      else.
> 
>      In theory, with the fix for bug 1300864 *and* the APZ frame 
>      delay (bug 1375949) in place, if we can paint the page
>      within the 16 ms frame budget, scrolling should be perfect.
> 
>      So, if we are in fact painting within the frame budget,
>      and still not scrolling perfectly, it means there's another 
>      underlying issue which we need to be diagnosed.