Title: [230665] trunk
Revision
230665
Author
grao...@webkit.org
Date
2018-04-15 22:38:01 -0700 (Sun, 15 Apr 2018)

Log Message

[Web Animations] Animations do not naturally get a finish event
https://bugs.webkit.org/show_bug.cgi?id=184639
<rdar://problem/39397649>

Reviewed by Jon Lee.

LayoutTests/imported/w3c:

Record two progressions in the Web Animations WPT tests.

* web-platform-tests/web-animations/timing-model/animations/updating-the-finished-state-expected.txt:

Source/WebCore:

We must call updateFinishedState() when an animation gets sampled as it means its timeline's time has progressed
and it may have crossed to a finished state. Calling updateFinishedState() when sampling means that we'll correctly
set the animation's hold time to its end value, which means that currentTime() will now always be clamped to return
the end time once its has reached it, so we must not schedule animations to resolve immediately anymore since otherwise
they will keep being scheduled in a loop.

* animation/WebAnimation.cpp:
(WebCore::WebAnimation::timeToNextRequiredTick const):
(WebCore::WebAnimation::resolve):

Modified Paths

Diff

Modified: trunk/LayoutTests/imported/w3c/ChangeLog (230664 => 230665)


--- trunk/LayoutTests/imported/w3c/ChangeLog	2018-04-16 01:01:18 UTC (rev 230664)
+++ trunk/LayoutTests/imported/w3c/ChangeLog	2018-04-16 05:38:01 UTC (rev 230665)
@@ -1,3 +1,15 @@
+2018-04-15  Antoine Quint  <grao...@apple.com>
+
+        [Web Animations] Animations do not naturally get a finish event
+        https://bugs.webkit.org/show_bug.cgi?id=184639
+        <rdar://problem/39397649>
+
+        Reviewed by Jon Lee.
+
+        Record two progressions in the Web Animations WPT tests.
+
+        * web-platform-tests/web-animations/timing-model/animations/updating-the-finished-state-expected.txt:
+
 2018-04-15  Chris Dumez  <cdu...@apple.com>
 
         Change Event's returnValue so it doesn't expose a new primitive

Modified: trunk/LayoutTests/imported/w3c/web-platform-tests/web-animations/timing-model/animations/updating-the-finished-state-expected.txt (230664 => 230665)


--- trunk/LayoutTests/imported/w3c/web-platform-tests/web-animations/timing-model/animations/updating-the-finished-state-expected.txt	2018-04-16 01:01:18 UTC (rev 230664)
+++ trunk/LayoutTests/imported/w3c/web-platform-tests/web-animations/timing-model/animations/updating-the-finished-state-expected.txt	2018-04-16 05:38:01 UTC (rev 230665)
@@ -1,8 +1,8 @@
 
-FAIL Updating the finished state when playing past end assert_equals: Hold time is set to target end clamping current time expected 100000 but got 100029
+PASS Updating the finished state when playing past end 
 PASS Updating the finished state when seeking past end 
 PASS Updating the finished state when seeking exactly to end 
-FAIL Updating the finished state when playing in reverse past zero assert_equals: Hold time is set to zero clamping current time expected 0 but got -15
+PASS Updating the finished state when playing in reverse past zero 
 PASS Updating the finished state when seeking a reversed animation past zero 
 FAIL Updating the finished state when seeking a reversed animation exactly to zero assert_equals: Hold time is set so current time should NOT change expected 0 but got -0
 PASS Updating the finished state when playing before end 

Modified: trunk/Source/WebCore/ChangeLog (230664 => 230665)


--- trunk/Source/WebCore/ChangeLog	2018-04-16 01:01:18 UTC (rev 230664)
+++ trunk/Source/WebCore/ChangeLog	2018-04-16 05:38:01 UTC (rev 230665)
@@ -1,3 +1,21 @@
+2018-04-15  Antoine Quint  <grao...@apple.com>
+
+        [Web Animations] Animations do not naturally get a finish event
+        https://bugs.webkit.org/show_bug.cgi?id=184639
+        <rdar://problem/39397649>
+
+        Reviewed by Jon Lee.
+
+        We must call updateFinishedState() when an animation gets sampled as it means its timeline's time has progressed
+        and it may have crossed to a finished state. Calling updateFinishedState() when sampling means that we'll correctly
+        set the animation's hold time to its end value, which means that currentTime() will now always be clamped to return
+        the end time once its has reached it, so we must not schedule animations to resolve immediately anymore since otherwise
+        they will keep being scheduled in a loop.
+
+        * animation/WebAnimation.cpp:
+        (WebCore::WebAnimation::timeToNextRequiredTick const):
+        (WebCore::WebAnimation::resolve):
+
 2018-04-15  Chris Dumez  <cdu...@apple.com>
 
         Change Event's returnValue so it doesn't expose a new primitive

Modified: trunk/Source/WebCore/animation/WebAnimation.cpp (230664 => 230665)


--- trunk/Source/WebCore/animation/WebAnimation.cpp	2018-04-16 01:01:18 UTC (rev 230664)
+++ trunk/Source/WebCore/animation/WebAnimation.cpp	2018-04-16 05:38:01 UTC (rev 230665)
@@ -1003,11 +1003,6 @@
     if (localTime < 0_s)
         return -localTime;
 
-    // If our current time is just at the acthive duration threshold we want to invalidate as
-    // soon as possible to restore a non-animated value.
-    if (std::abs(localTime.microseconds() - m_effect->timing()->activeDuration().microseconds()) < timeEpsilon.microseconds())
-        return 0_s;
-
     // In any other case, we're idle or already outside our active duration and have no need
     // to schedule an invalidation.
     return Seconds::infinity();
@@ -1017,6 +1012,8 @@
 {
     if (m_effect)
         m_effect->apply(targetStyle);
+
+    updateFinishedState(DidSeek::No, SynchronouslyNotify::Yes);
 }
 
 void WebAnimation::setSuspended(bool isSuspended)
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to