In case all the relevant animations for the document are accelerated, we should not be calling updateAnimationsAndSendEvents().
<rdar://problem/45356027>
Created attachment 354546 [details] Patch
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
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
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?
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
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
(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.
Tracking the Windows failures in https://bugs.webkit.org/show_bug.cgi?id=191584.
Committed r238128: <https://trac.webkit.org/changeset/238128>
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