[Web Animations] Make WPT test at timing-model/timelines/document-timelines.html...
authorgraouts@webkit.org <graouts@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 30 Jun 2018 13:43:26 +0000 (13:43 +0000)
committergraouts@webkit.org <graouts@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 30 Jun 2018 13:43:26 +0000 (13:43 +0000)
commit1f8117960cf0d9ae725d90ab9a11426fdad5bdaa
tree44743d4cf333453f05eba55fc78e0897de9d888a
parent5c9046db92da3951cf266450ed90a31755c80770
[Web Animations] Make WPT test at timing-model/timelines/document-timelines.html pass reliably
https://bugs.webkit.org/show_bug.cgi?id=186507
<rdar://problem/41000257>

Reviewed by Dean Jackson.

LayoutTests/imported/w3c:

Record WPT test progressions.

* web-platform-tests/web-animations/timing-model/timelines/document-timelines-expected.txt:

Source/WebCore:

The Web Animations spec, along with the HTML5 event loop spec, specify some assumptions on the time reported by
document.timeline.currentTime:

- it should only increase once per frame
- it should have the same value as the timestamp passed to requestAnimationFrame() callbacks

The WPT test at web-platform-tests/web-animations/timing-model/timelines/document-timelines.html relies on these
assumptions to be true so that we check that the start time of a new animation is not the same as the timeline time
when it was created, since it will be in the "play-pending" state for a frame.

In order to support this, we add two new methods on DocumentAnimationScheduler. First, when a scheduled display update
fires, we record the timestamp and expose it via lastTimestamp() such that DocumentTimeline and ScriptedAnimationController
can use the same value when updating animations. Then, to know whether code is run as a result of a display update, we
expose isFiring().

Now, within DocumentTimeline::currentTime(), we can cache the current time this way:

- if we're in the middle of a display update, use the value returned by lastTimestamp().
- otherwise, compute what would have been the ideal number of frames (at 60fps or less if throttled) and add those to
the lastTimestamp() value.

Then, we remove this cached current time when both currently-running JavaScript has completed and all animation update
code has completed by waiting on the invalidation task to run.

* animation/DocumentAnimationScheduler.cpp:
(WebCore::DocumentAnimationScheduler::displayRefreshFired):
* animation/DocumentAnimationScheduler.h:
(WebCore::DocumentAnimationScheduler::lastTimestamp):
(WebCore::DocumentAnimationScheduler::isFiring const):
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::currentTime):
(WebCore::DocumentTimeline::performInvalidationTask):
(WebCore::DocumentTimeline::maybeClearCachedCurrentTime):
* animation/DocumentTimeline.h:
* dom/ScriptedAnimationController.cpp:
(WebCore::ScriptedAnimationController::serviceScriptedAnimations):
(WebCore::ScriptedAnimationController::documentAnimationSchedulerDidFire):

LayoutTests:

This test now passes reliably.

* TestExpectations:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@233394 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests/ChangeLog
LayoutTests/TestExpectations
LayoutTests/imported/w3c/ChangeLog
LayoutTests/imported/w3c/web-platform-tests/web-animations/timing-model/timelines/document-timelines-expected.txt
Source/WebCore/ChangeLog
Source/WebCore/animation/DocumentAnimationScheduler.cpp
Source/WebCore/animation/DocumentAnimationScheduler.h
Source/WebCore/animation/DocumentTimeline.cpp
Source/WebCore/animation/DocumentTimeline.h
Source/WebCore/dom/ScriptedAnimationController.cpp