Title: [230665] trunk
- Revision
- 230665
- Author
- [email protected]
- 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 <[email protected]>
+
+ [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 <[email protected]>
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 <[email protected]>
+
+ [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 <[email protected]>
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
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
