animated elements with filter effects stutter
Categories
(Core :: Graphics: WebRender, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox72 | --- | wontfix |
firefox73 | --- | wontfix |
firefox74 | --- | fixed |
People
(Reporter: martin.pesl, Assigned: aosmond)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, testcase)
Attachments
(2 files)
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•5 years ago
|
||
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
Updated•5 years ago
|
Comment 2•5 years ago
|
||
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.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
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).
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
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.
Pushed by aosmond@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9867a7bc911e Stop snapping when calculating uv rects on the CPU side. r=gw
Comment 6•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Description
•