1353399 - Intermittent reftest failure 1298742-1.html with webrender enabled

Status: RESOLVED FIXED

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

Comment 1

[Mason Chang [Inactive] [:mchang]]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1298742#c30

Comment 2

[Hiroyuki Ikezoe (:hiro)]

Mason, please put a link to failure log here. I'd like to see the result difference. Thanks!

Comment 3

[Mason Chang [Inactive] [:mchang]]

Is there a reason you didn't make the animation times the same or figure out why it was intermittent on try per https://bugzilla.mozilla.org/show_bug.cgi?id=1298742#c24 ?

Comment 4

[Mason Chang [Inactive] [:mchang]]

Failure log here - https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/YYm4i_08S1KYlkCcwKZymg/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Thank you Mason.
I did not actually check the failure on try at that time, so I have no idea about its reason.
What I can tell about the failure diff in comment 4 is that we failed to pull (had no chance?) the animation from the compositor before we got MozAfterPaint event.  It reminds me bug 1341294 again.

Comment 6

[Mason Chang [Inactive] [:mchang]]

I think this is a problem with the test. It has two animations. Once the animations are paused and ready, we remove one of the animations. The first animation is then queued and can start at anytime, which races with the removal of reftest-wait and snapshotting I think. But it seems also like this test is fundamentally flawed if the original test had intermittents.

Comment 7

[Boris Chiou [:boris]]

Sorry, I'm not familiar with the potential race problem of the removal of reftest-wait and snapshotting. I think hiro/Brian has more ideas about this intermittent failure.

Comment 8

[Brian Birtles (:birtles)]

Boris, is the problem here the following:

    animB.effect = null;
    requestAnimationFrame(function() {
      document.documentElement.classList.remove("reftest-wait");
    });

i.e. we have animB on the compositor and we might snapshot before the compositor has been updated?

Comment 9

[Boris Chiou [:boris]]

(In reply to Brian Birtles (:birtles, away until 19 Sep) from comment #8)
> Boris, is the problem here the following:
> 
>     animB.effect = null;
>     requestAnimationFrame(function() {
>       document.documentElement.classList.remove("reftest-wait");
>     });
> 
> i.e. we have animB on the compositor and we might snapshot before the
> compositor has been updated?

This test wants to test if we set the keyframe effect of animB to null, animB will have no effect on this element, but I'm not sure what happen on compositor thread. If it is on the main thread, everything seems OK. However, if animB is on the compositor thread, and we set its keyframe effect to null, then we should remove it from the compositor thread, so the visual result of this element becomes animA, which is 'translate(0px)'. i.e. I thought we need to snapshot after animB is updated on the compositor thread? Maybe we forget do something so this may break the test after enabling webrender.

Comment 10

[Brian Birtles (:birtles)]

I wonder if bug 1397057 fixes this.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

This was fixed by bug 1404091. But there's a stale comment in the reftest.list that needs removing.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1477d8efa569
Remove stale comment. r=me and DONTBUILD

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/1477d8efa569