1611601 - animated elements with filter effects stutter

Status: RESOLVED FIXED

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

Description

[martin.pesl]

Attachment: minimal example

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

Steps to reproduce:

• create a div element with fixed size
• add background image to div
• add css filters to div
• add css animation to div

Actual results:

Animation jumps back and forth which results in a stutter effect.
More filter effects on the element increase the stutter effect.

Expected results:

Animation should display in a smooth motion as in older versions.

Comment 1

[Jan Sonntag]

Thanks for your comprehensive report!
I can reproduce your bug in the latest Nightly. Seems to be a regression from the WebRender snapping redesign.

mozregression gives me the following:
Last good revision: a8b8823a6b72114f4150fbcd2ab0728b833b6a04
First bad revision: ef5f9e04f04b648bdee5517bcbf71895acf2314e
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a8b8823a6b72114f4150fbcd2ab0728b833b6a04&tochange=ef5f9e04f04b648bdee5517bcbf71895acf2314e

Comment 2

[Jan Sonntag]

Speed of the animation also seems to be important. If you set animation-duration: 1s and transform: translateY(200px) the stutter disappears even with all filters enabled.
NI Andrew Osmond because he can probably help the most here.

Comment 3

[Andrew Osmond [:aosmond] (he/him)]

Thank you for the excellent reduced test case. This has revealed to me an interesting feedback loop:

Here we produce the precise local rect including the effect of any shadows:
https://searchfox.org/mozilla-central/rev/2e355fa82aaa87e8424a9927c8136be184eeb6c7/gfx/wr/webrender/src/prim_store/mod.rs#2031

We include this is our primitive local rect calculation:
https://searchfox.org/mozilla-central/rev/2e355fa82aaa87e8424a9927c8136be184eeb6c7/gfx/wr/webrender/src/prim_store/mod.rs#2086

Which gets folded into the surface rect:
https://searchfox.org/mozilla-central/rev/2e355fa82aaa87e8424a9927c8136be184eeb6c7/gfx/wr/webrender/src/prim_store/mod.rs#2216

And if that aggregate doesn't match the original precise local rect, then we update the precise local rect:
https://searchfox.org/mozilla-central/rev/2e355fa82aaa87e8424a9927c8136be184eeb6c7/gfx/wr/webrender/src/prim_store/mod.rs#2342

Additionally, the snapping of the surface rect appears to be related:
https://searchfox.org/mozilla-central/rev/2e355fa82aaa87e8424a9927c8136be184eeb6c7/gfx/wr/webrender/src/prim_store/mod.rs#2324

This actually could cause a feedback loop on the precise local rect (precise affect shadow, shadow affects local, local affects surface, surface affects precise, repeat), I suspect all the way up the picture tree.

However all that considered, it does not appear this in of itself is causing the shaking. Investigation continues, although the above will need to be fixed as well (and may cause it's own class of snapping issues).

Comment 4

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Bug 1611601 - Stop snapping when calculating uv rects on the CPU side.

In bug 1574493, we moved most snapping to scene building and a minority
to frame building. No snapping is done in the shader. However there was
some left over code that still tried to replicate the past behaviour and
this caused wobbling during the rendering. This patch removes the extra
snapping on the CPU side and trusts scene/frame building to do the job.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9867a7bc911e
Stop snapping when calculating uv rects on the CPU side. r=gw

Comment 6

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/9867a7bc911e