Closed
Bug 1505363
Opened 6 years ago
Closed 6 years ago
Animated element sometimes flashes at the end of the animation
Categories
(Core :: Graphics: WebRender, defect, P4)
Tracking
()
RESOLVED
FIXED
mozilla66
People
(Reporter: nchevobbe, Assigned: sotaro)
References
()
Details
Attachments
(3 files)
(deleted),
video/mp4
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/x-phabricator-request
|
Details |
**Steps to reproduce**
1. Go to `data:text/html,<meta charset=utf8><style>h1 {animation: 1.1s linear appears;}@keyframes appears {0% {opacity: 0;}100% {opacity: 1;}}</style><h1>Hello</h1>`
**Expected results**
The "Hello" text slowly appears. At the end of the animation, the text stays visible
**Actual results**
Sometimes, there's a flash at the end of the animation (see attached screencast, at 2-3s).
You can reload the tab a few times, I usually reproduce this in 3 tries.
This only seems to happen with webRender enabled
---
Updated•6 years ago
|
Blocks: stage-wr-trains
Updated•6 years ago
|
Priority: -- → P3
Assignee | ||
Comment 3•6 years ago
|
||
I tried the STR in comment 0 with latest nightly on osx, win10 and linux, but could not reproduce the problem.
Assignee | ||
Comment 4•6 years ago
|
||
It might be similar to Bug 1497852.
Updated•6 years ago
|
Comment 5•6 years ago
|
||
Getting a WR capture here would probably help. Might not be too hard to modify the code to just grab a capture for every frame in an OMTA and then just pick out the bad frame.
Comment 6•6 years ago
|
||
Nicolas, can you reproduce this problem on Windows?
Flags: needinfo?(nchevobbe)
Priority: P3 → P4
Assignee | ||
Comment 7•6 years ago
|
||
I could reproduce the problem by adding latency in LowPrioritySceneBuilder::process_transaction() from it. The problem seemed to be caused by async animation.
Assignee | ||
Comment 8•6 years ago
|
||
Assignee: nobody → sotaro.ikeda.g
Assignee | ||
Comment 9•6 years ago
|
||
With attachment 9034650 [details] [diff] [review] , I reproduce the parobem with STR in comment 0.
And when I disabled async animation by pref layers.offmainthreadcomposition.async-animations:false, I did not see the problem.
Assignee | ||
Comment 10•6 years ago
|
||
WebRenderBridgeParent::RemoveEpochDataPriorTo() seems to delete animation too early.
WebRenderLayerManager::DiscardCompositorAnimations() was called just before calling WrBridge()->EndTransaction() in WebRenderLayerManager::EndTransactionWithoutLayer(). Then WebRenderBridgeParent::RecvDeleteCompositorAnimations() was called just before WebRenderBridgeParent::RecvSetDisplayList() call. The RecvSetDisplayList() update WrEpoch. Then the RecvDeleteCompositorAnimations() stored old epoch in mCompositorAnimationsToDelete.
https://dxr.mozilla.org/mozilla-central/source/gfx/layers/wr/WebRenderBridgeParent.cpp#778
Assignee | ||
Comment 11•6 years ago
|
||
It seems better to call WebRenderLayerManager::DiscardCompositorAnimations() after calling WrBridge()->EndTransaction() in WebRenderLayerManager::EndTransactionWithoutLayer().
Assignee | ||
Comment 12•6 years ago
|
||
Reporter | ||
Comment 13•6 years ago
|
||
> Nicolas, can you reproduce this problem on Windows?
I tried with the STR, reloading the page ~50 times and couldn't reproduce it.
Reporter | ||
Updated•6 years ago
|
Flags: needinfo?(nchevobbe)
Assignee | ||
Comment 14•6 years ago
|
||
Comment 15•6 years ago
|
||
Pushed by sikeda@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ed51ef14289e
Call DiscardCompositorAnimations() after calling WrBridge()->EndTransaction() r=kats
Assignee | ||
Updated•6 years ago
|
OS: Mac OS X → All
Comment 16•6 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox66:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Updated•6 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•