Animated element sometimes flashes at the end of the animation

RESOLVED FIXED in Firefox 66

Status

()

P4
normal
RESOLVED FIXED
3 months ago
5 days ago

People

(Reporter: nchevobbe, Assigned: sotaro)

Tracking

(Blocks: 1 bug)

Trunk
mozilla66
Unspecified
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox65 disabled, firefox66 fixed)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

3 months ago
Created attachment 9023254 [details]
end of animation glitch

**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

---
Blocks: 1386669
Priority: -- → P3
What platform do you see this on?
Flags: needinfo?(nchevobbe)
(Reporter)

Comment 2

a month ago
OSX
Flags: needinfo?(nchevobbe)
(Assignee)

Comment 3

a month 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

a month ago
It might be similar to Bug 1497852.
See Also: → bug 1497852
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.
Nicolas, can you reproduce this problem on Windows?
Flags: needinfo?(nchevobbe)
Priority: P3 → P4
(Assignee)

Comment 7

17 days 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

17 days ago
Created attachment 9034650 [details] [diff] [review]
temporal patch - Add latency to LowPrioritySceneBuilder::process_transaction()
Assignee: nobody → sotaro.ikeda.g
(Assignee)

Comment 9

17 days 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

17 days 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

17 days ago
It seems better to call WebRenderLayerManager::DiscardCompositorAnimations() after calling WrBridge()->EndTransaction() in WebRenderLayerManager::EndTransactionWithoutLayer().
(Assignee)

Updated

17 days ago
Blocks: 1458414
(Assignee)

Comment 12

17 days ago
Created attachment 9034652 [details]
Bug 1505363 - Call DiscardCompositorAnimations() after calling WrBridge()->EndTransaction()
(Reporter)

Comment 13

17 days 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

17 days ago
Flags: needinfo?(nchevobbe)
(Assignee)

Updated

17 days ago
Blocks: 1497852

Comment 15

16 days 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

16 days ago
OS: Mac OS X → All

Comment 16

16 days ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 16 days ago
status-firefox66: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
status-firefox65: affected → disabled
Duplicate of this bug: 1514389
You need to log in before you can comment on or make changes to this bug.