Bug 191542 – [Web Animations] Don't schedule animation frames or update style while an accelerated animation is running

• Status: RESOLVED
• Resolution: FIXED
• Component: Animations

[Antoine Quint]

In case all the relevant animations for the document are accelerated, we should not be calling updateAnimationsAndSendEvents().

[Antoine Quint]

<rdar://problem/45356027>

[Antoine Quint]

Created attachment 354546 [details]
Patch

[EWS Watchlist]

Comment on attachment 354546 [details]
Patch

Attachment 354546 [details] did not pass mac-wk2-ews (mac-wk2):
Output: https://webkit-queues.webkit.org/results/9957516

New failing tests:
fast/layers/no-clipping-overflow-hidden-added-after-transform.html

[EWS Watchlist]

Created attachment 354553 [details]
Archive of layout-test-results from ews104 for mac-sierra-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews104  Port: mac-sierra-wk2  Platform: Mac OS X 10.12.6

[Simon Fraser (smfr)]

Comment on attachment 354546 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=354546&action=review

> Source/WebCore/animation/DocumentTimeline.cpp:316
> +    m_waitingOnVMIdle = true;
> +    if (!m_currentTimeClearingTaskQueue.hasPendingTasks())
> +        m_currentTimeClearingTaskQueue.enqueueTask(std::bind(&DocumentTimeline::maybeClearCachedCurrentTime, this));
> +    m_document->vm().whenIdle([this, protectedThis = makeRefPtr(this)]() {
> +        m_waitingOnVMIdle = false;
> +        maybeClearCachedCurrentTime();
> +    });

Is the VM going idle correct in terms of HTMLEventLoop behaviors, or is this a stop-gap until we have that?

[EWS Watchlist]

Comment on attachment 354546 [details]
Patch

Attachment 354546 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/9958403

New failing tests:
animations/transform-non-accelerated.html
animations/play-state-paused.html
webanimations/accelerated-animation-with-delay.html
animations/animation-direction-reverse.html
webanimations/accelerated-transition-by-removing-property.html
http/wpt/css/css-animations/set-animation-play-state-to-paused-001.html
transitions/start-transform-transition.html
fast/animation/css-animation-resuming-when-visible-with-style-change.html
animations/animation-direction-normal.html
animations/dynamic-stylesheet-loading.html

[EWS Watchlist]

Created attachment 354561 [details]
Archive of layout-test-results from ews200 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews200  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

[Antoine Quint]

(In reply to Simon Fraser (smfr) from comment #5)
> Comment on attachment 354546 [details]
> 
> Is the VM going idle correct in terms of HTMLEventLoop behaviors, or is this
> a stop-gap until we have that?

The latter. This is just so that I can tell for sure that we always return the same current time for the given animation frame. This works well in practice.

[Antoine Quint]

Tracking the Windows failures in https://bugs.webkit.org/show_bug.cgi?id=191584.

[Antoine Quint]

Committed r238128: <https://trac.webkit.org/changeset/238128>

[Truitt Savell]

It looks like https://trac.webkit.org/changeset/238128/webkit has caused 

imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html

to become flakey. Confirmed using command:
run-webkit-tests --root debug-238128 imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html --iterations 1000 -f --debug -1

The test fails around 15 times out of the 1000. test does not fail at all on 238127.

Diff:
--- /Volumes/Data/slave/highsierra-debug-tests-wk1/build/layout-test-results/imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt
+++ /Volumes/Data/slave/highsierra-debug-tests-wk1/build/layout-test-results/imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-actual.txt
@@ -1,7 +1,7 @@
 
 PASS Fires cancel event before requestAnimationFrame 
 PASS Fires finish event before requestAnimationFrame 
-FAIL Sorts finish events by composite order assert_array_equals: finish events for various animation type should be sorted by composite order property 0, expected "CSSTransition:finish" but got "ScriptAnimation:finish"
+PASS Sorts finish events by composite order 
 FAIL Sorts cancel events by composite order assert_array_equals: cancel events should be sorted by composite order lengths differ, expected 5 got 3
 FAIL Sorts events for the same transition assert_array_equals: Playback and CSS events for the same transition should be sorted by schedule event time and composite order lengths differ, expected 2 got 1
 PASS Playback events with the same timeline retain the order in which they arequeued