dom/base/test/test_domwindowutils.html | Opacity animation should run on the compositor
Categories
(GeckoView :: General, defect, P1)
Tracking
(firefox67 fixed)
| Tracking | Status | |
|---|---|---|
| firefox67 | --- | fixed |
People
(Reporter: intermittent-bug-filer, Assigned: birtles)
References
Details
Attachments
(1 file)
#[markdown(off)]
Filed by: jwillcox [at] mozilla.com
https://treeherder.mozilla.org/logviewer.html#?job_id=224565847&repo=try
Brian, do you have ideas on this? It only seems to happen with GeckoView/e10s.
|
Assignee | |
Comment 2•6 years ago
|
||
I don't see anything at a glance. The times in the log look good, i.e. it's not that the animation runs to completion before we check the flag (on the contrary, it's more likely we're querying the flag too soon--but that too seems unlikely given that we're waiting on the ready promise). That flag gets set on the main thread though so it shouldn't depend on the compositor process.
I made up a similar test case to check that opacity animations like this are in fact running on the compositor under the Reference Browser and inspecting the animation using DevTools it appears that they are:
Perhaps we can do a try run with paint listener debugging turned on for this test.
Hiro wrote this test so maybe he has ideas too.
|
|
Assignee | |
Comment 3•6 years ago
|
||
The other thing we can do is dump the output of JSON.stringify(SpecialPowers.wrap(animation.effect).getProperties()) to see if there is any particular performance warning we're hitting.
|
||
Comment 4•6 years ago
|
||
As per the try result, this is not a perma failure, we probably need to make sure the animation is sent to the compositor just like we do with waitForAnimationReadyToRestyle() in testcommon.js.
|
|
Assignee | |
Comment 5•6 years ago
|
||
Ok great. Here is a try run with some logging:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e5e98571eb4b978d658e9b9eccd8bd9d8eaf19a1
And another one with waitForAnimationReadyToRestyle():
https://treeherder.mozilla.org/#/jobs?repo=try&revision=c34c9013395796ea4db769e3449c0396ad8b2803
(I haven't tried either locally so hopefully they run)
|
|
Assignee | |
Comment 6•6 years ago
|
||
Actual try run with tests enabled (thanks Hiro for pointing that out!):
https://treeherder.mozilla.org/#/jobs?repo=try&revision=0993c94fb7f5a3fb10445e22618f774df510f81b
|
|
Assignee | |
Comment 7•6 years ago
|
||
This test was failing intermittently on GeckoView e10s. The
waitForAnimationReadyToRestyle helper works around certain cases where, due to
vsync, the animation ends up starting at exactly the same frame time as when it
was created meaning that restyling may not get triggered and hence we won't have
a chance to send it to the compositor.
It's not clear why this happens more frequently on GeckoView e10s but this seems
to fix the failures anyway.
|
|
Assignee | |
Comment 8•6 years ago
|
||
Do you think this may explain some of the test_restyles failures as well? Do we need a similar fix there?
|
||
Comment 11•6 years ago
|
||
| bugherder | ||
|
|
||
Comment 12•6 years ago
|
||
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #10)
Do you think this may explain some of the test_restyles failures as well? Do we need a similar fix there?
It's plausible. But the place that the test fails is after calling pause(), it should be fairly cheap (given that we've never seen such failures on Fennec). So I am wondering GeckoView is more slower than Fennec?. It's worrisome. Anyway, we should add await waitForAnimationReadyToRestyle(animation) after the pause().
| Comment hidden (Intermittent Failures Robot) |
Description
•