2017-10-20 18:41:23 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2017 Apple Inc. All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY APPLE INC. ``AS IS'' AND ANY
|
|
|
|
|
* EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
|
|
|
|
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE INC. OR
|
|
|
|
|
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
|
|
|
|
|
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
|
|
|
|
|
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
|
|
|
|
|
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
|
|
|
|
|
* OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
|
|
|
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
|
|
#include "AnimationTimeline.h"
|
2018-07-09 23:52:54 +00:00
|
|
|
#include "DocumentTimelineOptions.h"
|
[Web Animations] Schedule animations registered on the document timeline
https://bugs.webkit.org/show_bug.cgi?id=179236
<rdar://problem/35332669>
Reviewed by Dean Jackson.
Source/WebCore:
We now schedule animations contained in the document timeline using a three-step approach.
1. Each time an object that is part of the timing model changes one of its timing properties, we call
animationTimingModelDidChange() on the document timeline. This schedules performInvalidationTask()
to be called when the current run loop completes, such that we invalidate the timing model just once
per run loop.
2. Once performInvalidationTask() is called, the timing model is invalidated in updateAnimationSchedule().
We iterate over the registered animations on the timineline and identify the shortest interval between
the current time and the next moment one of the animations requires a tick to update its value. If we
find a value below 15ms, we schedule animations to be resolved with scheduleAnimationResolution() right
away. If the value is above 15ms, and not inifinity, we schedule a one-shot timer for that interval to
call scheduleAnimationResolution().
3. Once scheduleAnimationResolution() is called, we call scheduleAnimation() on the shared DisplayRefreshMonitorManager
to be notified when the next display refresh occurs to actually resolve animations with resolveAnimations().
Note that, in this patch, resolveAnimations() does nothing, we will add support for interpolating values in
a future patch.
Another important thing to note is that every time the document timeline's current time is requested, we cache
it for the duration of the run loop such that the timing model always uses the same value during a given run loop.
Finally, to support tests where we check the state of the timing model by manually advancing time, we expose a
new pause() method on AnimationTimeline for tests to call to avoid the timeline to self-advance.
* animation/AnimationTimeline.cpp:
(WebCore::AnimationTimeline::addAnimation): Mark that the timing model changed as a result of adding an animation.
(WebCore::AnimationTimeline::removeAnimation): Mark that the timing model changed as a result of removing an animation.
(WebCore::AnimationTimeline::bindingsCurrentTime): Update the method signature to no longer be const and call into
currentTime() instead of reading directly from the m_currentTime member variable since a subclass, like DocumentTimeline,
may have a custom currentTime() implementation.
(WebCore::AnimationTimeline::setCurrentTime): Mark that the timing model changed as a result of the timeline current time
changing.
(WebCore::AnimationTimeline::bindingsCurrentTime const): Deleted.
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::currentTime): Change both methods signatures to no longer be const so that DocumentTimeline's
implementation of currentTime() may cache the current time in a member variable, enqueuing a callback when the run loop
completes for this member variable to be reset, and updating some states.
(WebCore::AnimationTimeline::pause): To be implemented by subclasses.
(WebCore::AnimationTimeline::animationTimingModelDidChange): Add a new virtual method to indicate that the timing model
needs invalidating.
(WebCore::AnimationTimeline::animations const): Add an accessor to allow animations to be accessed by a subclass.
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::create):
(WebCore::DocumentTimeline::DocumentTimeline): Update the constructor signature to receive a Document and a PlatformDisplayID
since we need a reference to the Document to get at the nowTime() and a PlatformDisplayID to create the DisplayRefreshMonitor.
(WebCore::DocumentTimeline::~DocumentTimeline): Close the task queue when the timeline gets destroyed.
(WebCore::DocumentTimeline::currentTime): If we don't have a current cahed current time, compute one and schedule
the invalidation task if needed so that we may reset the cached value as the run loop completes.
(WebCore::DocumentTimeline::pause): Allows the timeline not to self-advance, for testing purposes only.
(WebCore::DocumentTimeline::animationTimingModelDidChange): If we haven't already done so, mark that we need to update our
animation schedule in the invalidation task and schedule that task if not scheduled yet.
(WebCore::DocumentTimeline::scheduleInvalidationTaskIfNeeded): Schedule the invalidation task to run as the run loop completes
if we haven't already done so.
(WebCore::DocumentTimeline::performInvalidationTask): Update the animation schedule if needed and reset the cached current
time value.
(WebCore::DocumentTimeline::updateAnimationSchedule): Iterate over registed animations and find the shortest interval until
one of them needs to update their animation. If the shortest interval is below 15ms, schedule the animation resolution right
away. If the shortest inverval is finite and above 15ms, then schedule a one-shot timer for that interval to perform the
animation resolution then.
(WebCore::DocumentTimeline::animationScheduleTimerFired): The one-shot timer to perform the animation resolution has fired,
we call scheduleAnimationResolution().
(WebCore::DocumentTimeline::scheduleAnimationResolution): We call scheduleAnimation() on the shared DisplayRefreshMonitorManager
so that we may resolve animations on the next display refresh, or start a timer if the DisplayRefreshMonitorManager is not available.
(WebCore::DocumentTimeline::displayRefreshFired): The display is about to refresh, we call resolveAnimations().
(WebCore::DocumentTimeline::animationResolutionTimerFired): The fallback animation resolution timer has fired, we call resolveAnimations().
(WebCore::DocumentTimeline::resolveAnimations): Currently do nothing, this is where we'll iterate over registered animations to
update them with the current time.
(WebCore::DocumentTimeline::windowScreenDidChange): Notify the shared DisplayRefreshMonitorManager that the PlatformDisplayID
changed.
(WebCore::DocumentTimeline::createDisplayRefreshMonitor const): Provide a DisplayRefreshMonitor as part of the
DisplayRefreshMonitorClient protocol.
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::create): Remove extra white space.
(WebCore::WebAnimation::setStartTime): Mark that the timing model changed as a result of changing this animation's start time.
(WebCore::WebAnimation::timeToNextRequiredTick const): Compute the interval until the next time we need to resolve this animation.
If the provided current time is before this animation's start time, compute the delay until the start time. If the current time
is after the animation's start time but before the animation's end time, indicate that we want to resolve the animation again
right away and return 0ms. In any other case, return an infinite interval to indicate that we don't need to be refreshed after
the provided time.
* animation/WebAnimation.h:
* dom/Document.cpp:
(WebCore::Document::windowScreenDidChange): Notify the document timeline that the PlatformDisplayID changed.
(WebCore::Document::timeline): Provide the Document and the PlatformDisplayID to the DocumentTimeline.
* testing/Internals.cpp:
(WebCore::Internals::pauseTimeline):
* testing/Internals.h:
* testing/Internals.idl:
LayoutTests:
Adopt the new internals.pauseTimeline() method to ensure that the existing
tests do not have a self-advancing timeline since we're interested in checking
the timing model state based on manually setting the timeline current time.
Also update some WPT expectations with some progressions.
* TestExpectations: Mark two tests as flaky due to the sample time being logged
in the failure.
* http/wpt/web-animations/interfaces/AnimationTimeline/document-timeline-expected.txt:
* http/wpt/web-animations/timing-model/animations/current-time-expected.txt:
* http/wpt/web-animations/timing-model/animations/set-the-animation-start-time-expected.txt:
* http/wpt/wk-web-animations/timing-model/animation-creation-basic.html:
* http/wpt/wk-web-animations/timing-model/animation-current-time.html:
* http/wpt/wk-web-animations/timing-model/animation-effect-timing.html:
* http/wpt/wk-web-animations/timing-model/animation-effect.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-effect-property.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-start-time-property.html:
* http/wpt/wk-web-animations/timing-model/animation-playback-rate.html:
* http/wpt/wk-web-animations/timing-model/document-timeline.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect-interface-timing-duration.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect.html:
* http/wpt/wk-web-animations/timing-model/timeline-current-time.html:
Canonical link: https://commits.webkit.org/195397@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@224472 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-11-05 22:34:10 +00:00
|
|
|
#include "Timer.h"
|
2017-10-20 18:41:23 +00:00
|
|
|
#include <wtf/Ref.h>
|
2020-01-27 12:01:21 +00:00
|
|
|
#include <wtf/WeakPtr.h>
|
2017-10-20 18:41:23 +00:00
|
|
|
|
|
|
|
|
namespace WebCore {
|
|
|
|
|
|
[Web Animations] Ensure CSS Transition and CSS Animation events are queued, sorted and dispatched by their timeline
https://bugs.webkit.org/show_bug.cgi?id=207364
<rdar://problem/59370413>
Reviewed by Simon Fraser.
LayoutTests/imported/w3c:
There are some progressions but also some "regressions". The progressions are real, showing the delivery of all animation events at the correct
time. However, the regressions are misleading. The fact that the "style change" tests would work was due to a design issue in the test which would
only wait one frame to detect whether a CSS Transition was started after a change made through the Web Animations API. These would work because
events were queued in the next frame, but delivered later due to the dedicated per-animation queue used, which meant the test was fooled into
thinking the CSS Transition did not start, as expected. Changing those test to use more than one frame to test for the lack of a CSS Transition
would have shown the FAIL results.
However, in order to not regress our WPT score, the issue of "style change" events will be addressed in a follow-up patch.
* web-platform-tests/css/css-transitions/CSSTransition-startTime.tentative-expected.txt:
* web-platform-tests/web-animations/interfaces/Animatable/animate-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/style-change-events-expected.txt:
* web-platform-tests/web-animations/interfaces/KeyframeEffect/style-change-events-expected.txt:
* web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt:
Source/WebCore:
Until now, AnimationPlaybackEvent events, which are new events introduced by the Web Animations spec, were enqueued in a shared queue on the DocumentTimeline
and dispatched during the "update animations and send events" procedure. However, AnimationEvent and TransitionEvent events, dispatched by CSS Animations
and CSS Transitions, were dispatched via a dedicated per-animation queue, which meant typically that those events were dispathed one runloop after the
AnimationPlaybackEvent events.
We now remove the dedicated per-animation queue and enqueue all events in the shared DocumentTimeline queue for dispatch during the "update animations and send
events" procedure. To do this correctly, we need to do a couple of other things that ensure we don't regress tests.
First, we update the DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState() to account for whether there are pending animation events,
guaranteeing that an animation update is scheduled should there be any.
Second, when animation events are enqueued in DocumentTimeline::enqueueAnimationEvent() we schedule an animation update if needed, since we know we now
have pending events that will need to be delivered in an upcoming update. We also maintain a flag between the start of the "update animations and send events"
procedure and the moment when the pending animation events queue is cleared prior to dispatching events so that events enqueued in the meantime do not
prematurely schedule animation resolution. The need for a new animation resolution will be checked at the end of the procedure.
Finally, declarative animations used to have a special suclass of WebAnimation::needsTick() that would check whether they had any pending events, ensuring
they would not be removed prematurely. We now reset a flag to false as WebAnimation::tick() is called (as part of the "update animations and send events"
procedure) and set it to true in case an animation is enqueued. This flag is then used in needsTick() to guarantee the animation is not removed before
the DocumentTimeline has had a chance to dispatch the enqueued event.
Note also that, for clarity, the DocumentTimeline::unscheduleAnimationResolution() was renamed to DocumentTimeline::clearTickScheduleTimer() since it wouldn't
actually cancel a previous animation resolution schedule.
* animation/CSSTransition.h: Fix a newly found build error due to the missing wtf/MonotonicTime.h header.
* animation/DeclarativeAnimation.cpp: Remove all code related to the dedicated per-animation queue and instead call the new WebAnimation::enqueueAnimationEvent()
method to enqueue events on the DocumentTimeline.
(WebCore::DeclarativeAnimation::DeclarativeAnimation):
(WebCore::DeclarativeAnimation::tick):
(WebCore::DeclarativeAnimation::enqueueDOMEvent):
* animation/DeclarativeAnimation.h:
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::detachFromDocument): Ensure the pending events queue is cleared when the timeline is detached from a document, ensuring that there no
longer events that would cause a ref-cycle (DocumentTimeline -> AnimationPlaybackEvent -> WebAnimation -> DocumentTimeline).
(WebCore::DocumentTimeline::suspendAnimations):
(WebCore::DocumentTimeline::removeAnimation):
(WebCore::DocumentTimeline::scheduleAnimationResolution):
(WebCore::DocumentTimeline::clearTickScheduleTimer):
(WebCore::DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState const):
(WebCore::DocumentTimeline::updateCurrentTime):
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::scheduleNextTick):
(WebCore::DocumentTimeline::animationAcceleratedRunningStateDidChange):
(WebCore::DocumentTimeline::enqueueAnimationEvent):
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::enqueueAnimationPlaybackEvent):
(WebCore::WebAnimation::enqueueAnimationEvent):
(WebCore::WebAnimation::needsTick const):
(WebCore::WebAnimation::tick):
* animation/WebAnimation.h:
LayoutTests:
Fix a couple of tests that made some incorrect assumptions.
* TestExpectations: imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html is no longer flaky.
* compositing/backing/animate-into-view.html: Because the "animationstart" event is now dispatched during the "update animations and send events" procedure, which happens
during page rendering _before_ rAF callbacks are serviced, we must remove the rAF callback used prior to adding the "animationstart" event listener or else we would never
get it and the test would time out.
* webanimations/css-transition-in-flight-reversal-accelerated.html: We must wait for the initial transition to start and then two frames before reversing the transition,
to be certain that the animation did start. Indeed, the "transitionstart" event will be fired right before the next rAF callback is called, as the animation starts in that
very same frame, and so progress will be 0 and the transition wouldn't be reversable until the next frame when the animation has progress > 0.
Canonical link: https://commits.webkit.org/220724@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256619 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-02-14 17:52:07 +00:00
|
|
|
class AnimationEventBase;
|
2020-04-22 07:16:51 +00:00
|
|
|
class DocumentTimelinesController;
|
2020-09-25 15:22:00 +00:00
|
|
|
class RenderBoxModelObject;
|
2017-11-24 13:30:36 +00:00
|
|
|
class RenderElement;
|
|
|
|
|
|
2020-02-26 10:21:29 +00:00
|
|
|
class DocumentTimeline final : public AnimationTimeline
|
[Web Animations] Schedule animations registered on the document timeline
https://bugs.webkit.org/show_bug.cgi?id=179236
<rdar://problem/35332669>
Reviewed by Dean Jackson.
Source/WebCore:
We now schedule animations contained in the document timeline using a three-step approach.
1. Each time an object that is part of the timing model changes one of its timing properties, we call
animationTimingModelDidChange() on the document timeline. This schedules performInvalidationTask()
to be called when the current run loop completes, such that we invalidate the timing model just once
per run loop.
2. Once performInvalidationTask() is called, the timing model is invalidated in updateAnimationSchedule().
We iterate over the registered animations on the timineline and identify the shortest interval between
the current time and the next moment one of the animations requires a tick to update its value. If we
find a value below 15ms, we schedule animations to be resolved with scheduleAnimationResolution() right
away. If the value is above 15ms, and not inifinity, we schedule a one-shot timer for that interval to
call scheduleAnimationResolution().
3. Once scheduleAnimationResolution() is called, we call scheduleAnimation() on the shared DisplayRefreshMonitorManager
to be notified when the next display refresh occurs to actually resolve animations with resolveAnimations().
Note that, in this patch, resolveAnimations() does nothing, we will add support for interpolating values in
a future patch.
Another important thing to note is that every time the document timeline's current time is requested, we cache
it for the duration of the run loop such that the timing model always uses the same value during a given run loop.
Finally, to support tests where we check the state of the timing model by manually advancing time, we expose a
new pause() method on AnimationTimeline for tests to call to avoid the timeline to self-advance.
* animation/AnimationTimeline.cpp:
(WebCore::AnimationTimeline::addAnimation): Mark that the timing model changed as a result of adding an animation.
(WebCore::AnimationTimeline::removeAnimation): Mark that the timing model changed as a result of removing an animation.
(WebCore::AnimationTimeline::bindingsCurrentTime): Update the method signature to no longer be const and call into
currentTime() instead of reading directly from the m_currentTime member variable since a subclass, like DocumentTimeline,
may have a custom currentTime() implementation.
(WebCore::AnimationTimeline::setCurrentTime): Mark that the timing model changed as a result of the timeline current time
changing.
(WebCore::AnimationTimeline::bindingsCurrentTime const): Deleted.
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::currentTime): Change both methods signatures to no longer be const so that DocumentTimeline's
implementation of currentTime() may cache the current time in a member variable, enqueuing a callback when the run loop
completes for this member variable to be reset, and updating some states.
(WebCore::AnimationTimeline::pause): To be implemented by subclasses.
(WebCore::AnimationTimeline::animationTimingModelDidChange): Add a new virtual method to indicate that the timing model
needs invalidating.
(WebCore::AnimationTimeline::animations const): Add an accessor to allow animations to be accessed by a subclass.
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::create):
(WebCore::DocumentTimeline::DocumentTimeline): Update the constructor signature to receive a Document and a PlatformDisplayID
since we need a reference to the Document to get at the nowTime() and a PlatformDisplayID to create the DisplayRefreshMonitor.
(WebCore::DocumentTimeline::~DocumentTimeline): Close the task queue when the timeline gets destroyed.
(WebCore::DocumentTimeline::currentTime): If we don't have a current cahed current time, compute one and schedule
the invalidation task if needed so that we may reset the cached value as the run loop completes.
(WebCore::DocumentTimeline::pause): Allows the timeline not to self-advance, for testing purposes only.
(WebCore::DocumentTimeline::animationTimingModelDidChange): If we haven't already done so, mark that we need to update our
animation schedule in the invalidation task and schedule that task if not scheduled yet.
(WebCore::DocumentTimeline::scheduleInvalidationTaskIfNeeded): Schedule the invalidation task to run as the run loop completes
if we haven't already done so.
(WebCore::DocumentTimeline::performInvalidationTask): Update the animation schedule if needed and reset the cached current
time value.
(WebCore::DocumentTimeline::updateAnimationSchedule): Iterate over registed animations and find the shortest interval until
one of them needs to update their animation. If the shortest interval is below 15ms, schedule the animation resolution right
away. If the shortest inverval is finite and above 15ms, then schedule a one-shot timer for that interval to perform the
animation resolution then.
(WebCore::DocumentTimeline::animationScheduleTimerFired): The one-shot timer to perform the animation resolution has fired,
we call scheduleAnimationResolution().
(WebCore::DocumentTimeline::scheduleAnimationResolution): We call scheduleAnimation() on the shared DisplayRefreshMonitorManager
so that we may resolve animations on the next display refresh, or start a timer if the DisplayRefreshMonitorManager is not available.
(WebCore::DocumentTimeline::displayRefreshFired): The display is about to refresh, we call resolveAnimations().
(WebCore::DocumentTimeline::animationResolutionTimerFired): The fallback animation resolution timer has fired, we call resolveAnimations().
(WebCore::DocumentTimeline::resolveAnimations): Currently do nothing, this is where we'll iterate over registered animations to
update them with the current time.
(WebCore::DocumentTimeline::windowScreenDidChange): Notify the shared DisplayRefreshMonitorManager that the PlatformDisplayID
changed.
(WebCore::DocumentTimeline::createDisplayRefreshMonitor const): Provide a DisplayRefreshMonitor as part of the
DisplayRefreshMonitorClient protocol.
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::create): Remove extra white space.
(WebCore::WebAnimation::setStartTime): Mark that the timing model changed as a result of changing this animation's start time.
(WebCore::WebAnimation::timeToNextRequiredTick const): Compute the interval until the next time we need to resolve this animation.
If the provided current time is before this animation's start time, compute the delay until the start time. If the current time
is after the animation's start time but before the animation's end time, indicate that we want to resolve the animation again
right away and return 0ms. In any other case, return an infinite interval to indicate that we don't need to be refreshed after
the provided time.
* animation/WebAnimation.h:
* dom/Document.cpp:
(WebCore::Document::windowScreenDidChange): Notify the document timeline that the PlatformDisplayID changed.
(WebCore::Document::timeline): Provide the Document and the PlatformDisplayID to the DocumentTimeline.
* testing/Internals.cpp:
(WebCore::Internals::pauseTimeline):
* testing/Internals.h:
* testing/Internals.idl:
LayoutTests:
Adopt the new internals.pauseTimeline() method to ensure that the existing
tests do not have a self-advancing timeline since we're interested in checking
the timing model state based on manually setting the timeline current time.
Also update some WPT expectations with some progressions.
* TestExpectations: Mark two tests as flaky due to the sample time being logged
in the failure.
* http/wpt/web-animations/interfaces/AnimationTimeline/document-timeline-expected.txt:
* http/wpt/web-animations/timing-model/animations/current-time-expected.txt:
* http/wpt/web-animations/timing-model/animations/set-the-animation-start-time-expected.txt:
* http/wpt/wk-web-animations/timing-model/animation-creation-basic.html:
* http/wpt/wk-web-animations/timing-model/animation-current-time.html:
* http/wpt/wk-web-animations/timing-model/animation-effect-timing.html:
* http/wpt/wk-web-animations/timing-model/animation-effect.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-effect-property.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-start-time-property.html:
* http/wpt/wk-web-animations/timing-model/animation-playback-rate.html:
* http/wpt/wk-web-animations/timing-model/document-timeline.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect-interface-timing-duration.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect.html:
* http/wpt/wk-web-animations/timing-model/timeline-current-time.html:
Canonical link: https://commits.webkit.org/195397@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@224472 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-11-05 22:34:10 +00:00
|
|
|
{
|
2017-10-20 18:41:23 +00:00
|
|
|
public:
|
2018-06-25 09:54:34 +00:00
|
|
|
static Ref<DocumentTimeline> create(Document&);
|
2018-07-09 23:52:54 +00:00
|
|
|
static Ref<DocumentTimeline> create(Document&, DocumentTimelineOptions&&);
|
[Web Animations] Schedule animations registered on the document timeline
https://bugs.webkit.org/show_bug.cgi?id=179236
<rdar://problem/35332669>
Reviewed by Dean Jackson.
Source/WebCore:
We now schedule animations contained in the document timeline using a three-step approach.
1. Each time an object that is part of the timing model changes one of its timing properties, we call
animationTimingModelDidChange() on the document timeline. This schedules performInvalidationTask()
to be called when the current run loop completes, such that we invalidate the timing model just once
per run loop.
2. Once performInvalidationTask() is called, the timing model is invalidated in updateAnimationSchedule().
We iterate over the registered animations on the timineline and identify the shortest interval between
the current time and the next moment one of the animations requires a tick to update its value. If we
find a value below 15ms, we schedule animations to be resolved with scheduleAnimationResolution() right
away. If the value is above 15ms, and not inifinity, we schedule a one-shot timer for that interval to
call scheduleAnimationResolution().
3. Once scheduleAnimationResolution() is called, we call scheduleAnimation() on the shared DisplayRefreshMonitorManager
to be notified when the next display refresh occurs to actually resolve animations with resolveAnimations().
Note that, in this patch, resolveAnimations() does nothing, we will add support for interpolating values in
a future patch.
Another important thing to note is that every time the document timeline's current time is requested, we cache
it for the duration of the run loop such that the timing model always uses the same value during a given run loop.
Finally, to support tests where we check the state of the timing model by manually advancing time, we expose a
new pause() method on AnimationTimeline for tests to call to avoid the timeline to self-advance.
* animation/AnimationTimeline.cpp:
(WebCore::AnimationTimeline::addAnimation): Mark that the timing model changed as a result of adding an animation.
(WebCore::AnimationTimeline::removeAnimation): Mark that the timing model changed as a result of removing an animation.
(WebCore::AnimationTimeline::bindingsCurrentTime): Update the method signature to no longer be const and call into
currentTime() instead of reading directly from the m_currentTime member variable since a subclass, like DocumentTimeline,
may have a custom currentTime() implementation.
(WebCore::AnimationTimeline::setCurrentTime): Mark that the timing model changed as a result of the timeline current time
changing.
(WebCore::AnimationTimeline::bindingsCurrentTime const): Deleted.
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::currentTime): Change both methods signatures to no longer be const so that DocumentTimeline's
implementation of currentTime() may cache the current time in a member variable, enqueuing a callback when the run loop
completes for this member variable to be reset, and updating some states.
(WebCore::AnimationTimeline::pause): To be implemented by subclasses.
(WebCore::AnimationTimeline::animationTimingModelDidChange): Add a new virtual method to indicate that the timing model
needs invalidating.
(WebCore::AnimationTimeline::animations const): Add an accessor to allow animations to be accessed by a subclass.
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::create):
(WebCore::DocumentTimeline::DocumentTimeline): Update the constructor signature to receive a Document and a PlatformDisplayID
since we need a reference to the Document to get at the nowTime() and a PlatformDisplayID to create the DisplayRefreshMonitor.
(WebCore::DocumentTimeline::~DocumentTimeline): Close the task queue when the timeline gets destroyed.
(WebCore::DocumentTimeline::currentTime): If we don't have a current cahed current time, compute one and schedule
the invalidation task if needed so that we may reset the cached value as the run loop completes.
(WebCore::DocumentTimeline::pause): Allows the timeline not to self-advance, for testing purposes only.
(WebCore::DocumentTimeline::animationTimingModelDidChange): If we haven't already done so, mark that we need to update our
animation schedule in the invalidation task and schedule that task if not scheduled yet.
(WebCore::DocumentTimeline::scheduleInvalidationTaskIfNeeded): Schedule the invalidation task to run as the run loop completes
if we haven't already done so.
(WebCore::DocumentTimeline::performInvalidationTask): Update the animation schedule if needed and reset the cached current
time value.
(WebCore::DocumentTimeline::updateAnimationSchedule): Iterate over registed animations and find the shortest interval until
one of them needs to update their animation. If the shortest interval is below 15ms, schedule the animation resolution right
away. If the shortest inverval is finite and above 15ms, then schedule a one-shot timer for that interval to perform the
animation resolution then.
(WebCore::DocumentTimeline::animationScheduleTimerFired): The one-shot timer to perform the animation resolution has fired,
we call scheduleAnimationResolution().
(WebCore::DocumentTimeline::scheduleAnimationResolution): We call scheduleAnimation() on the shared DisplayRefreshMonitorManager
so that we may resolve animations on the next display refresh, or start a timer if the DisplayRefreshMonitorManager is not available.
(WebCore::DocumentTimeline::displayRefreshFired): The display is about to refresh, we call resolveAnimations().
(WebCore::DocumentTimeline::animationResolutionTimerFired): The fallback animation resolution timer has fired, we call resolveAnimations().
(WebCore::DocumentTimeline::resolveAnimations): Currently do nothing, this is where we'll iterate over registered animations to
update them with the current time.
(WebCore::DocumentTimeline::windowScreenDidChange): Notify the shared DisplayRefreshMonitorManager that the PlatformDisplayID
changed.
(WebCore::DocumentTimeline::createDisplayRefreshMonitor const): Provide a DisplayRefreshMonitor as part of the
DisplayRefreshMonitorClient protocol.
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::create): Remove extra white space.
(WebCore::WebAnimation::setStartTime): Mark that the timing model changed as a result of changing this animation's start time.
(WebCore::WebAnimation::timeToNextRequiredTick const): Compute the interval until the next time we need to resolve this animation.
If the provided current time is before this animation's start time, compute the delay until the start time. If the current time
is after the animation's start time but before the animation's end time, indicate that we want to resolve the animation again
right away and return 0ms. In any other case, return an infinite interval to indicate that we don't need to be refreshed after
the provided time.
* animation/WebAnimation.h:
* dom/Document.cpp:
(WebCore::Document::windowScreenDidChange): Notify the document timeline that the PlatformDisplayID changed.
(WebCore::Document::timeline): Provide the Document and the PlatformDisplayID to the DocumentTimeline.
* testing/Internals.cpp:
(WebCore::Internals::pauseTimeline):
* testing/Internals.h:
* testing/Internals.idl:
LayoutTests:
Adopt the new internals.pauseTimeline() method to ensure that the existing
tests do not have a self-advancing timeline since we're interested in checking
the timing model state based on manually setting the timeline current time.
Also update some WPT expectations with some progressions.
* TestExpectations: Mark two tests as flaky due to the sample time being logged
in the failure.
* http/wpt/web-animations/interfaces/AnimationTimeline/document-timeline-expected.txt:
* http/wpt/web-animations/timing-model/animations/current-time-expected.txt:
* http/wpt/web-animations/timing-model/animations/set-the-animation-start-time-expected.txt:
* http/wpt/wk-web-animations/timing-model/animation-creation-basic.html:
* http/wpt/wk-web-animations/timing-model/animation-current-time.html:
* http/wpt/wk-web-animations/timing-model/animation-effect-timing.html:
* http/wpt/wk-web-animations/timing-model/animation-effect.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-effect-property.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-start-time-property.html:
* http/wpt/wk-web-animations/timing-model/animation-playback-rate.html:
* http/wpt/wk-web-animations/timing-model/document-timeline.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect-interface-timing-duration.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect.html:
* http/wpt/wk-web-animations/timing-model/timeline-current-time.html:
Canonical link: https://commits.webkit.org/195397@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@224472 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-11-05 22:34:10 +00:00
|
|
|
~DocumentTimeline();
|
|
|
|
|
|
2019-01-10 08:19:39 +00:00
|
|
|
bool isDocumentTimeline() const final { return true; }
|
|
|
|
|
|
[Web Animations] Correct implementation of pending tasks and promises
https://bugs.webkit.org/show_bug.cgi?id=183161
Reviewed by Dean Jackson.
LayoutTests/imported/w3c:
Update test expectations with progressions (+32 WPT PASS).
* web-platform-tests/web-animations/interfaces/Animatable/animate-no-browsing-context-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/finish-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/finished-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/onfinish-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/pause-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/pending-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/startTime-expected.txt:
* web-platform-tests/web-animations/timing-model/animations/canceling-an-animation-expected.txt:
* web-platform-tests/web-animations/timing-model/animations/pausing-an-animation-expected.txt:
* web-platform-tests/web-animations/timing-model/animations/play-states-expected.txt:
* web-platform-tests/web-animations/timing-model/animations/reversing-an-animation-expected.txt:
* web-platform-tests/web-animations/timing-model/animations/set-the-animation-start-time-expected.txt:
* web-platform-tests/web-animations/timing-model/animations/set-the-target-effect-of-an-animation-expected.txt:
* web-platform-tests/web-animations/timing-model/animations/set-the-timeline-of-an-animation-expected.txt:
Source/WebCore:
We had an incorrect implementation of the spec due to two misinterpretations.
The first one is about pending tasks (play and pause) which the spec says should
be performed by "scheduling a task". In WebCore, this means using postTask() on a
ScriptExecutionContext, such as Document. One of the big practical changes is that
calling play() on an animation correctly sets its startTime to null (unresolved)
immediately after the call to play() returns before setting it to a resolved value
when the task is performed asynchronously. As a result, the playState is now always
accurate.
The second one is about promises where new promises need to be created in certain
situations called out by the spec. We used to call clear() on them, but this merely
resets the fulfillment or rejection state of the promise, while the spec requires
a different object to be returned for the promise. We now create our promises using
makeUniqueRef<> when new promise objects are expected to be created.
This patch also corrects a few smaller bugs and spec compliant issues, called out
below, related to pending tasks and promises uncovered while looking at relevant
WPT tests.
* animation/DocumentTimeline.h: Expose the Document used to create this timeline such
that it may be used by WebAnimation objects registered for this timeline when scheduling
a task is required via postTask().
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::WebAnimation):
(WebCore::WebAnimation::setBindingsStartTime):
(WebCore::WebAnimation::setCurrentTime):
(WebCore::WebAnimation::cancel): Ensure the finished promise has not already been fulfilled
before rejecting it. While the spec does not specifically call this out, a promise may not
be rejected after being fulfilled, and we would hit an ASSERT if we didn't also check that
it was in the correct pending state before attemping to reject it.
(WebCore::WebAnimation::resetPendingTasks):
(WebCore::WebAnimation::finish):
(WebCore::WebAnimation::updateFinishedState):
(WebCore::WebAnimation::finishNotificationSteps):
(WebCore::WebAnimation::play): We used to only check for a pending pause task before canceling
that task, but the spec says to check for either a pending pause or play task (ie. pending())
and to cancel whichever is scheduled.
(WebCore::WebAnimation::runPendingPlayTask): We were missing an assertion called out by the
spec when running a pending task.
(WebCore::WebAnimation::pause):
(WebCore::WebAnimation::runPendingPauseTask):
(WebCore::WebAnimation::updatePendingTasks): We now use postTask() on the animation's associated
timeline's document to schedule pending tasks for which the criteria to run are met, ie. there
is an associated timeline.
* animation/WebAnimation.h:
Canonical link: https://commits.webkit.org/198880@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@229069 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-02-27 21:05:02 +00:00
|
|
|
Document* document() const { return m_document.get(); }
|
|
|
|
|
|
2021-05-30 16:11:40 +00:00
|
|
|
std::optional<Seconds> currentTime() override;
|
[Web Animations] Schedule animations registered on the document timeline
https://bugs.webkit.org/show_bug.cgi?id=179236
<rdar://problem/35332669>
Reviewed by Dean Jackson.
Source/WebCore:
We now schedule animations contained in the document timeline using a three-step approach.
1. Each time an object that is part of the timing model changes one of its timing properties, we call
animationTimingModelDidChange() on the document timeline. This schedules performInvalidationTask()
to be called when the current run loop completes, such that we invalidate the timing model just once
per run loop.
2. Once performInvalidationTask() is called, the timing model is invalidated in updateAnimationSchedule().
We iterate over the registered animations on the timineline and identify the shortest interval between
the current time and the next moment one of the animations requires a tick to update its value. If we
find a value below 15ms, we schedule animations to be resolved with scheduleAnimationResolution() right
away. If the value is above 15ms, and not inifinity, we schedule a one-shot timer for that interval to
call scheduleAnimationResolution().
3. Once scheduleAnimationResolution() is called, we call scheduleAnimation() on the shared DisplayRefreshMonitorManager
to be notified when the next display refresh occurs to actually resolve animations with resolveAnimations().
Note that, in this patch, resolveAnimations() does nothing, we will add support for interpolating values in
a future patch.
Another important thing to note is that every time the document timeline's current time is requested, we cache
it for the duration of the run loop such that the timing model always uses the same value during a given run loop.
Finally, to support tests where we check the state of the timing model by manually advancing time, we expose a
new pause() method on AnimationTimeline for tests to call to avoid the timeline to self-advance.
* animation/AnimationTimeline.cpp:
(WebCore::AnimationTimeline::addAnimation): Mark that the timing model changed as a result of adding an animation.
(WebCore::AnimationTimeline::removeAnimation): Mark that the timing model changed as a result of removing an animation.
(WebCore::AnimationTimeline::bindingsCurrentTime): Update the method signature to no longer be const and call into
currentTime() instead of reading directly from the m_currentTime member variable since a subclass, like DocumentTimeline,
may have a custom currentTime() implementation.
(WebCore::AnimationTimeline::setCurrentTime): Mark that the timing model changed as a result of the timeline current time
changing.
(WebCore::AnimationTimeline::bindingsCurrentTime const): Deleted.
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::currentTime): Change both methods signatures to no longer be const so that DocumentTimeline's
implementation of currentTime() may cache the current time in a member variable, enqueuing a callback when the run loop
completes for this member variable to be reset, and updating some states.
(WebCore::AnimationTimeline::pause): To be implemented by subclasses.
(WebCore::AnimationTimeline::animationTimingModelDidChange): Add a new virtual method to indicate that the timing model
needs invalidating.
(WebCore::AnimationTimeline::animations const): Add an accessor to allow animations to be accessed by a subclass.
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::create):
(WebCore::DocumentTimeline::DocumentTimeline): Update the constructor signature to receive a Document and a PlatformDisplayID
since we need a reference to the Document to get at the nowTime() and a PlatformDisplayID to create the DisplayRefreshMonitor.
(WebCore::DocumentTimeline::~DocumentTimeline): Close the task queue when the timeline gets destroyed.
(WebCore::DocumentTimeline::currentTime): If we don't have a current cahed current time, compute one and schedule
the invalidation task if needed so that we may reset the cached value as the run loop completes.
(WebCore::DocumentTimeline::pause): Allows the timeline not to self-advance, for testing purposes only.
(WebCore::DocumentTimeline::animationTimingModelDidChange): If we haven't already done so, mark that we need to update our
animation schedule in the invalidation task and schedule that task if not scheduled yet.
(WebCore::DocumentTimeline::scheduleInvalidationTaskIfNeeded): Schedule the invalidation task to run as the run loop completes
if we haven't already done so.
(WebCore::DocumentTimeline::performInvalidationTask): Update the animation schedule if needed and reset the cached current
time value.
(WebCore::DocumentTimeline::updateAnimationSchedule): Iterate over registed animations and find the shortest interval until
one of them needs to update their animation. If the shortest interval is below 15ms, schedule the animation resolution right
away. If the shortest inverval is finite and above 15ms, then schedule a one-shot timer for that interval to perform the
animation resolution then.
(WebCore::DocumentTimeline::animationScheduleTimerFired): The one-shot timer to perform the animation resolution has fired,
we call scheduleAnimationResolution().
(WebCore::DocumentTimeline::scheduleAnimationResolution): We call scheduleAnimation() on the shared DisplayRefreshMonitorManager
so that we may resolve animations on the next display refresh, or start a timer if the DisplayRefreshMonitorManager is not available.
(WebCore::DocumentTimeline::displayRefreshFired): The display is about to refresh, we call resolveAnimations().
(WebCore::DocumentTimeline::animationResolutionTimerFired): The fallback animation resolution timer has fired, we call resolveAnimations().
(WebCore::DocumentTimeline::resolveAnimations): Currently do nothing, this is where we'll iterate over registered animations to
update them with the current time.
(WebCore::DocumentTimeline::windowScreenDidChange): Notify the shared DisplayRefreshMonitorManager that the PlatformDisplayID
changed.
(WebCore::DocumentTimeline::createDisplayRefreshMonitor const): Provide a DisplayRefreshMonitor as part of the
DisplayRefreshMonitorClient protocol.
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::create): Remove extra white space.
(WebCore::WebAnimation::setStartTime): Mark that the timing model changed as a result of changing this animation's start time.
(WebCore::WebAnimation::timeToNextRequiredTick const): Compute the interval until the next time we need to resolve this animation.
If the provided current time is before this animation's start time, compute the delay until the start time. If the current time
is after the animation's start time but before the animation's end time, indicate that we want to resolve the animation again
right away and return 0ms. In any other case, return an infinite interval to indicate that we don't need to be refreshed after
the provided time.
* animation/WebAnimation.h:
* dom/Document.cpp:
(WebCore::Document::windowScreenDidChange): Notify the document timeline that the PlatformDisplayID changed.
(WebCore::Document::timeline): Provide the Document and the PlatformDisplayID to the DocumentTimeline.
* testing/Internals.cpp:
(WebCore::Internals::pauseTimeline):
* testing/Internals.h:
* testing/Internals.idl:
LayoutTests:
Adopt the new internals.pauseTimeline() method to ensure that the existing
tests do not have a self-advancing timeline since we're interested in checking
the timing model state based on manually setting the timeline current time.
Also update some WPT expectations with some progressions.
* TestExpectations: Mark two tests as flaky due to the sample time being logged
in the failure.
* http/wpt/web-animations/interfaces/AnimationTimeline/document-timeline-expected.txt:
* http/wpt/web-animations/timing-model/animations/current-time-expected.txt:
* http/wpt/web-animations/timing-model/animations/set-the-animation-start-time-expected.txt:
* http/wpt/wk-web-animations/timing-model/animation-creation-basic.html:
* http/wpt/wk-web-animations/timing-model/animation-current-time.html:
* http/wpt/wk-web-animations/timing-model/animation-effect-timing.html:
* http/wpt/wk-web-animations/timing-model/animation-effect.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-effect-property.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-start-time-property.html:
* http/wpt/wk-web-animations/timing-model/animation-playback-rate.html:
* http/wpt/wk-web-animations/timing-model/document-timeline.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect-interface-timing-duration.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect.html:
* http/wpt/wk-web-animations/timing-model/timeline-current-time.html:
Canonical link: https://commits.webkit.org/195397@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@224472 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-11-05 22:34:10 +00:00
|
|
|
|
[Web Animations] Implement the update animations and send events procedure
https://bugs.webkit.org/show_bug.cgi?id=191013
<rdar://problem/45620495>
Reviewed by Dean Jackson.
LayoutTests/imported/mozilla:
Progression in a couple of getAnimations() tests for CSS Animations.
* css-animations/test_document-get-animations-expected.txt:
LayoutTests/imported/w3c:
Progressions in a couple of Web Animations Web Platform Tests.
* web-platform-tests/web-animations/timing-model/animations/current-time-expected.txt:
* web-platform-tests/web-animations/timing-model/animations/updating-the-finished-state-expected.txt:
Source/WebCore:
While we implemented the various parts of what the Web Animations specification refers to as the "update animations and send events"
procedure, we did not implement it as one function and in the correct order, specifically updating animations and sending events in
two separate tasks. We now have a single method on DocumentTimeline which runs as the DisplayRefreshMonitor fires to update each
"relevant" animation with the current time, perform a microtask checkpoint and dispatch events.
Implementing this procedure allowed us to make several enhancements:
1. We introduce the concept of a "relevant" animation, which is essentially an animation that is either pending or playing. All animations
in a different state are no longer owned by the DocumentTimeline and can thus be destroyed if the developer doesn't hold references in JS.
Maintaining such a list guarantees that we're only updating animations that would have changed state since the last time the "update animations
and send events" procedure was run. Note that DeclarativeAnimation instances are also considered to be relevant if they have queued DOM events
to dispatch as they could otherwise be destroyed before they can fully dispatch them.
2. We no longer conflate the timing model and effects. Until now the way we would update animations was to go through all elements for which
we had a registered animation, invalidate their style and finally forcing a style update on the document. We had a separate data structure where
we help animations without targets so we update these as well in a separate pass, in order to make sure that promises and events would fire for
them as expected. We now let the "update animations and send events" procedure update the timing of all relevant animations and let individual
animation effects invalidate their style as needed, the document style invalidation happening naturally without DocumentTimeline forcing it.
3. We use a single step to schedule the update of animations, which is to register for a display refresh monitor update provided a "relevant"
animation is known since the previous update. Until now we first had an "timing model invalidation" task scheduled upon any change of an animation's
timing model, which would then create a timer to the earliest moment any listed animation would require an update, finally registering a display
refresh monitor update, which used at least GenericTaskQueue<Timer> and potentially two, whereas we use none right now.
4. We allow for a display refresh monitor update to be canceled should the number of "relevant" animations since the last update goes back to 0.
To facilitate all of this, we have changed the m_animations ListHashSet to contain only the "relevant" animations, and no longer every animation created
that has this DocumentTimeline set as their "timeline" property. To keep this list current, every single change that changes a given animation's timing
ends up calling AnimationTimeline::animationTimingDidChange() passing the animation as the sole parameter and adding this animation to m_animations. We
immediately schedule a display refresh monitor update if one wasn't already scheduled. Then, when running the "update animations and send events"
procedure, we call a new WebAnimation::tick() method on each of those animations, which updates this animation's effect and relevance, using the newly
computed relevance to identify whether this animation should be kept in the m_animations ListHashSet.
This is only the first step towards a more efficient update and ownership model of animations by the document timeline since animations created as CSS
Animations and CSS Transitions are committed through CSS have dedicated data structures that are not updated in this particular patch, but this will be
addressed in a followup to keep this already significant patch smaller. Another issue that will be addressed later is the ability to not schedule display
refresh monitor udpates when only accelerated animations are running.
* animation/AnimationTimeline.cpp:
(WebCore::AnimationTimeline::animationTimingDidChange): Called by animations when any aspect of their timing model changes. The provided animation is then
added to the m_animations list unless its timeline is no longer this timeline.
(WebCore::AnimationTimeline::removeAnimation): Remove the provided animation from m_animations and remove any animation registered on the element-specific
animation lists if this animation has an effect with a target.
(WebCore::AnimationTimeline::animationWasAddedToElement): We no longer need to worry about the m_animationsWithoutTarget data structure since we removed it.
(WebCore::removeCSSTransitionFromMap): Fix a bug where we would remove any CSSTransition in the provided map that had a matching transition-property instead
of checking the CSSTransition registered for this transition-property was indeed the provided CSSTransition. The other code changes in this patch made this
code now cause regressions in the Web Platform Tests.
(WebCore::AnimationTimeline::animationWasRemovedFromElement): Stop updating m_animationsWithoutTarget since it no longer exists.
(WebCore::AnimationTimeline::elementWasRemoved):
(WebCore::AnimationTimeline::updateCSSAnimationsForElement): Fix a small error that caused a regression in the Web Platform Tests where we could attempt to
call setBackingAnimation() on a nullptr instead of a valid CSSAnimation.
(WebCore::AnimationTimeline::cancelOrRemoveDeclarativeAnimation):
(WebCore::AnimationTimeline::addAnimation): Deleted.
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::hasElementAnimations const): Deleted.
(WebCore::AnimationTimeline:: const): Deleted.
(WebCore::AnimationTimeline::elementToAnimationsMap): Deleted.
(WebCore::AnimationTimeline::elementToCSSAnimationsMap): Deleted.
(WebCore::AnimationTimeline::elementToCSSTransitionsMap): Deleted.
* animation/CSSTransition.cpp:
(WebCore::CSSTransition::canBeListed const): Deleted.
* animation/CSSTransition.h:
* animation/DeclarativeAnimation.cpp:
(WebCore::DeclarativeAnimation::tick): Call the superclass's method and queue any necessary DOM events reflecting the timing model changes.
(WebCore::DeclarativeAnimation::needsTick const): Call the superclass's method and return true also if we have pending events since otherwise this animation
could be removed from m_animations on its AnimationTimeline and potentially destroyed before the GenericEventQueue had a chance to dispatch all events.
(WebCore::DeclarativeAnimation::startTime const): We removed the custom binding for this IDL property and renamed the method from bindingsStartTime to startTime.
(WebCore::DeclarativeAnimation::setStartTime): We removed the custom binding for this IDL property and renamed the method from setBindingsStartTime to setStartTime.
(WebCore::DeclarativeAnimation::bindingsStartTime const): Deleted.
(WebCore::DeclarativeAnimation::setBindingsStartTime): Deleted.
* animation/DeclarativeAnimation.h:
* animation/DocumentAnimationScheduler.cpp:
(WebCore::DocumentAnimationScheduler::unscheduleWebAnimationsResolution): Add a method to mark that we no longer need a display refresh monitor update for this
document's animation timeline. This is called when m_animations becomes empty.
* animation/DocumentAnimationScheduler.h:
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::DocumentTimeline):
(WebCore::DocumentTimeline::detachFromDocument): Stop clearing two task queues and a timer that no longer exist and instead only clear the task queue to clear
the cached current time, which we queue any time we generate a new one (see DocumentTimeline::currentTime).
(WebCore::DocumentTimeline::getAnimations const): Use isRelevant() instead of canBeListed().
(WebCore::DocumentTimeline::updateThrottlingState):
(WebCore::DocumentTimeline::suspendAnimations):
(WebCore::DocumentTimeline::resumeAnimations):
(WebCore::DocumentTimeline::numberOfActiveAnimationsForTesting const):
(WebCore::DocumentTimeline::currentTime): Queue a task in the new m_currentTimeClearingTaskQueue task queue to clear the current time that we've generated and cached
in the next run loop (provided all pending JS execution has also completed).
(WebCore::DocumentTimeline::maybeClearCachedCurrentTime):
(WebCore::DocumentTimeline::scheduleAnimationResolutionIfNeeded): Schedule a display refresh monitor update if we are not suspended and have "relevant" animations.
(WebCore::DocumentTimeline::animationTimingDidChange): Call scheduleAnimationResolutionIfNeeded() after calling the superclass's implementation.
(WebCore::DocumentTimeline::removeAnimation): Call unscheduleAnimationResolution() if the list of "relevant" animations is now empty.
(WebCore::DocumentTimeline::unscheduleAnimationResolution): Unschedule a pending display refresh monitor update.
(WebCore::DocumentTimeline::animationResolutionTimerFired):
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents): Implement the "update animations and send events" procedure as specified by the Web Animations spec.
During this procedure, we call tick() on all animations listed in m_animations and create a list of animations to remove from that list if this animation is no
longer relevant following the call to tick().
(WebCore::DocumentTimeline::enqueueAnimationPlaybackEvent):
(WebCore::DocumentTimeline::timingModelDidChange): Deleted.
(WebCore::DocumentTimeline::scheduleInvalidationTaskIfNeeded): Deleted.
(WebCore::DocumentTimeline::performInvalidationTask): Deleted.
(WebCore::DocumentTimeline::updateAnimationSchedule): Deleted.
(WebCore::DocumentTimeline::animationScheduleTimerFired): Deleted.
(WebCore::DocumentTimeline::updateAnimations): Deleted.
(WebCore::compareAnimationPlaybackEvents): Deleted.
(WebCore::DocumentTimeline::performEventDispatchTask): Deleted.
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp: The majority of the changes to this class is that we call the new timingDidChange() method when any code that modifies the timing model
is run. We also remove methods to set the pending play and pause tasks as well as the animation's start time and hold time since any time we're changing these instance
variables, we later already have a call to update the timing model and we were doing more work than needed. As a result we no longer need an internal method to set the
start time and can stop requiring a custom IDL binding for the "startTime" property.
(WebCore::WebAnimation::effectTimingPropertiesDidChange):
(WebCore::WebAnimation::setEffect):
(WebCore::WebAnimation::setEffectInternal):
(WebCore::WebAnimation::setTimeline):
(WebCore::WebAnimation::setTimelineInternal):
(WebCore::WebAnimation::startTime const):
(WebCore::WebAnimation::setStartTime):
(WebCore::WebAnimation::silentlySetCurrentTime):
(WebCore::WebAnimation::setCurrentTime):
(WebCore::WebAnimation::setPlaybackRate):
(WebCore::WebAnimation::cancel):
(WebCore::WebAnimation::resetPendingTasks):
(WebCore::WebAnimation::finish):
(WebCore::WebAnimation::timingDidChange): New method called any time a timing property changed where we run the "update the finished state" procedure and notify the
animation's timeline that its timing changed so that it can be considered the next time the "update animations and send events" procedure runs.
(WebCore::WebAnimation::invalidateEffect):
(WebCore::WebAnimation::updateFinishedState): Update the animation's relevance after running the procedure as specified.
(WebCore::WebAnimation::play):
(WebCore::WebAnimation::runPendingPlayTask):
(WebCore::WebAnimation::pause):
(WebCore::WebAnimation::runPendingPauseTask):
(WebCore::WebAnimation::needsTick const):
(WebCore::WebAnimation::tick): New method called during the "update animations and send events" procedure where we run the "update the finished state" procedure and run
the pending play and pause tasks.
(WebCore::WebAnimation::resolve):
(WebCore::WebAnimation::updateRelevance):
(WebCore::WebAnimation::computeRelevance):
(WebCore::WebAnimation::timingModelDidChange): Deleted.
(WebCore::WebAnimation::setHoldTime): Deleted.
(WebCore::WebAnimation::bindingsStartTime const): Deleted.
(WebCore::WebAnimation::setBindingsStartTime): Deleted.
(WebCore::WebAnimation::setTimeToRunPendingPlayTask): Deleted.
(WebCore::WebAnimation::setTimeToRunPendingPauseTask): Deleted.
(WebCore::WebAnimation::updatePendingTasks): Deleted.
(WebCore::WebAnimation::timeToNextRequiredTick const): Deleted.
(WebCore::WebAnimation::runPendingTasks): Deleted.
(WebCore::WebAnimation::canBeListed const): Deleted.
* animation/WebAnimation.h:
(WebCore::WebAnimation::isRelevant const):
(WebCore::WebAnimation::hasPendingPlayTask const):
(WebCore::WebAnimation::isEffectInvalidationSuspended):
* animation/WebAnimation.idl:
* dom/Element.cpp:
(WebCore::Element::getAnimations): Use isRelevant() instead of canBeListed().
LayoutTests:
Several tests that broke when turning Web Animations CSS Integration on by default are now passing. In the case of one test, we had to ensure
that the final animation frame had been committed before terminating the test or there would be a tiny image reference issue.
* TestExpectations:
* fast/layers/no-clipping-overflow-hidden-added-after-transform.html:
Canonical link: https://commits.webkit.org/205875@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@237587 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-10-30 09:30:03 +00:00
|
|
|
void animationTimingDidChange(WebAnimation&) override;
|
|
|
|
|
void removeAnimation(WebAnimation&) override;
|
[Web Animations] Coordinate "update animations and send events" procedure across multiple timelines
https://bugs.webkit.org/show_bug.cgi?id=202109
<rdar://problem/59470821>
Reviewed by Dean Jackson.
LayoutTests/imported/w3c:
Mark a new test as PASS which shows that we correctly perform a single microstask checkpoint when updating multiple timelines.
* web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt:
Source/WebCore:
So far, although we did manage multiple animation timelines per document, we mostly operated
under the assumption that there really was a single timeline. In this patch we make the
"update animations and send events" procedure, which is central to the lifecycle of animations,
work with multiple timelines such that a single microtask checkpoint is performed even with multiple
timelines, whereas we would perform one per timeline before. To do this, we move much of the logic
DocumentTimeline::updateAnimationsAndSendEvents() to DocumentTimelinesController where each step is
run across each timeline, rather than running all steps for each timeline one after the other,
respecting the single microtask checkpoint in the middle of the process.
To minimize code churn at this stage, we still keep a fair bit of logic in DocumentTimeline and,
while we remove updateAnimationsAndSendEvents(), internalUpdateAnimationsAndSendEvents() and
updateCurrentTime(), we expose three methods that allow to run the pre-flight sequence in
documentWillUpdateAnimationsAndSendEvents(), collect pending events in
prepareForPendingAnimationEventsDispatch() and run the post-flight sequence
in documentDidUpdateAnimationsAndSendEvents().
None of the logic changes, this is just moving code around. In the future, more patches will move
code from DocumentTimeline up to DocumentTimelinesController such that events are enqueued there,
and animation scheduling as well. But this already lets us pass a new test that used to flakily
reject promises in the WPT test web-animations/timing-model/timelines/update-and-send-events.html.
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::relevantAnimations const):
(WebCore::AnimationTimeline::allAnimations const):
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::documentWillUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::documentDidUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::prepareForPendingAnimationEventsDispatch):
(WebCore::DocumentTimeline::updateCurrentTime): Deleted.
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents): Deleted.
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents): Deleted.
* animation/DocumentTimeline.h:
* animation/DocumentTimelinesController.cpp:
(WebCore::DocumentTimelinesController::DocumentTimelinesController):
(WebCore::DocumentTimelinesController::updateAnimationsAndSendEvents):
* animation/DocumentTimelinesController.h:
* animation/WebAnimationTypes.h:
* dom/Document.cpp:
(WebCore::Document::ensureTimelinesController):
LayoutTests:
Remove the flaky expectation for the improved test.
* TestExpectations:
Canonical link: https://commits.webkit.org/223759@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260525 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-22 18:47:36 +00:00
|
|
|
void transitionDidComplete(RefPtr<CSSTransition>);
|
2018-10-01 17:44:39 +00:00
|
|
|
|
2018-04-12 16:34:42 +00:00
|
|
|
// If possible, compute the visual extent of any transform animation on the given renderer
|
|
|
|
|
// using the given rect, returning the result in the rect. Return false if there is some
|
|
|
|
|
// transform animation but we were unable to cheaply compute its effect on the extent.
|
|
|
|
|
bool computeExtentOfAnimation(RenderElement&, LayoutRect&) const;
|
2017-11-24 13:30:36 +00:00
|
|
|
std::unique_ptr<RenderStyle> animatedStyleForRenderer(RenderElement& renderer);
|
2018-04-12 16:34:42 +00:00
|
|
|
bool isRunningAnimationOnRenderer(RenderElement&, CSSPropertyID) const;
|
|
|
|
|
bool isRunningAcceleratedAnimationOnRenderer(RenderElement&, CSSPropertyID) const;
|
Source/WebCore:
[Web Animations] Perform accelerated animations when possible
https://bugs.webkit.org/show_bug.cgi?id=179973
<rdar://problem/34953922>
Reviewed by Dean Jackson.
When we're entering and leaving the active duration of an animation effect, we now check
whether the animation can be accelerated, using the existing CSSPropertyAnimation::animationOfPropertyIsAccelerated()
utility, and start and stop animations using the startAnimation() and animationFinished() functions on RenderBoxModelObject.
This patch is only a first step towards full support for accelerated animations,
there are two known issues at the moment. Because we're not blending the styles to perform
the animation, getComputedStyle() will not return the animated value (webkit.org/b/179974).
Additionally, if other animations happen to run later during the active state of an animation
that can run accelerated, we will not fall back to software-only animation for this
element and these animations will appear not to run (webkit.org/b/179975). These will be
addressed in follow-up patches.
Tests: webanimations/left-and-opacity-animation-yields-no-compositing.html
webanimations/opacity-animation-no-longer-composited-upon-completion.html
webanimations/opacity-animation-yields-compositing.html
webanimations/width-and-opacity-separate-animation-yields-no-compositing.html
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::updateAnimations): Check in the map of pending accelerated animations
to see if any animation requires toggling their active state after their styles have been invalidated.
(WebCore::DocumentTimeline::animationAcceleratedRunningStateDidChange): New function to
let animations indicate that they need to have their accelerated backing animation toggled after
style invalidation has been completed.
(WebCore::DocumentTimeline::runningAnimationsForElementAreAllAccelerated): This function is used
in RenderLayerCompositor::requiresCompositingForAnimation() to identify whether an element requires
hardware compositing due to running accelerated animations. We check all running animations for the
provided element to see if they can all be running accelerated and return true in this situation only.
* animation/DocumentTimeline.h:
* animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::applyAtLocalTime): Identify if we're crossing into or out of the active state
for an animation and check if it will be or has been running accelerated such that we can notify the
DocumentTimeline, through the associated animation, that the accelerated backing animation will need to
be toggled after style invalidation has been completed.
(WebCore::KeyframeEffect::shouldRunAccelerated): Check that all properties for this animation
effect can be accelerated according to CSSPropertyAnimation::animationOfPropertyIsAccelerated().
(WebCore::KeyframeEffect::startOrStopAccelerated): Start or stop the associated accelerated
animation through the associated element's RenderBoxModelObject renderer.
* animation/KeyframeEffect.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::acceleratedRunningStateDidChange): Called from AnimationEffect::applyAtLocalTime(),
we forward to the DocumentTimeline the information that the animation will cross an active state boundary while
allowing to be backed by hardware compositing.
(WebCore::WebAnimation::startOrStopAccelerated): Forward to the associated KeyframeEffect that accelerated
animation backing should be toggled.
* animation/WebAnimation.h:
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::requiresCompositingForAnimation const): Check via the renderer's element's
DocumentTimeline that all running animations for this particular element are accelerated to ensure that
the element will be hardware-composited.
LayoutTests:
[Web Animations] Perform hardware-composited animations when possible
https://bugs.webkit.org/show_bug.cgi?id=179973
<rdar://problem/34953922>
Reviewed by Dean Jackson.
Add a series of tests to check that we use hardware-compositing for animations when possible.
Specifically, we check that:
1. Specifying both accelerated and non-accelerated properties for a single animation does *not*
yield hardware compositing (left-and-opacity-animation-yields-no-compositing.html).
2. Specifying both accelerated and non-accelerated properties via multiple animations does *not*
yield hardware compositing (width-and-opacity-separate-animation-yields-no-compositing.html).
3. Specifying only accelerated properties *does* yield hardware compositing
(opacity-animation-yields-compositing.html).
4. Hardware-composited animations no longer enforce hardware compositing after their completion
(opacity-animation-no-longer-composited-upon-completion.html).
* webanimations/left-and-opacity-animation-yields-no-compositing-expected.txt: Added.
* webanimations/left-and-opacity-animation-yields-no-compositing.html: Added.
* webanimations/opacity-animation-no-longer-composited-upon-completion-expected.txt: Added.
* webanimations/opacity-animation-no-longer-composited-upon-completion.html: Added.
* webanimations/opacity-animation-yields-compositing-expected.txt: Added.
* webanimations/opacity-animation-yields-compositing.html: Added.
* webanimations/width-and-opacity-separate-animation-yields-no-compositing-expected.txt: Added.
* webanimations/width-and-opacity-separate-animation-yields-no-compositing.html: Added.
Canonical link: https://commits.webkit.org/195996@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@225128 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-11-24 09:45:30 +00:00
|
|
|
void animationAcceleratedRunningStateDidChange(WebAnimation&);
|
2020-09-25 15:22:00 +00:00
|
|
|
bool runningAnimationsForRendererAreAllAccelerated(const RenderBoxModelObject&) const;
|
[Web Animations] Implement getAnimations()
https://bugs.webkit.org/show_bug.cgi?id=179535
<rdar://problem/34932475>
Reviewed by Simon Fraser.
Source/WebCore:
We now allow a list of animations for a document, with Document.getAnimations(), or for an
element, with Animatable.getAnimations(), to be returned. In order to support this, we maintain
a map on AnimationTimeline of all animations for a given element. This map is invalidated
when an animation's timeline changes and when an animation's effect changes. Note that the
Web Animations spec mandates that an AnimationEffect can only be a single animation's effect.
Tests: http/wpt/wk-web-animations/interfaces/document-get-animations.html
http/wpt/wk-web-animations/interfaces/element-get-animations.html
http/wpt/wk-web-animations/timing-model/animation-effect-unique-relationship.html
* CMakeLists.txt: Add Animatable.idl.
* DerivedSources.make: Add Animatable.idl.
* WebCore.xcodeproj/project.pbxproj: Add Animatable.idl.
* animation/Animatable.idl: A new interface that Element implements and which currently only exposes
getAnimations(), the animate() method will be added later.
* animation/AnimationEffect.h: Add a new m_animation member to reference the animation using this
effect. This relationship is required so we guarantee that an effect is associated with a single
animation at most.
(WebCore::AnimationEffect::animation const):
(WebCore::AnimationEffect::setAnimation):
* animation/AnimationTimeline.cpp:
(WebCore::AnimationTimeline::animationWasAddedToElement): New method to notify the timeline that an
animation registered with this timeline has been associated with a new element through its effect.
(WebCore::AnimationTimeline::animationWasRemovedFromElement): New method to notify the timeline that an
animation registered with this timeline has been disassociated with an element through its effect.
(WebCore::AnimationTimeline::animationsForElement): New method returning all animations registered with
this timeline for a given element.
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::animations const): All animations registered with this timeline.
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::DocumentTimeline):
(WebCore::DocumentTimeline::detachFromDocument): Clear the reference between this timeline and its document.
(WebCore::DocumentTimeline::currentTime): Protect against a null Document reference.
(WebCore::DocumentTimeline::createDisplayRefreshMonitor const): Protect against a null Document reference.
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::create):
(WebCore::WebAnimation::setEffect): As an animation's effect changes, we need to ensure that the old
effect no longer has an associated animation, and that the new effect is associated with this animation.
Additionally, we update the element-to-animations map on the animation's timeline.
(WebCore::WebAnimation::setTimeline): Update the element-to-animations map on the former and new timeline.
* dom/Document.cpp:
(WebCore::Document::prepareForDestruction): Clear the relationship between this document and its timeline.
(WebCore::Document::getAnimations): Obtain all animations associated with this document's timeline.
* dom/Document.h:
* dom/Document.idl:
* dom/Element.cpp:
(WebCore::Element::getAnimations): Obtain all animations associated with this element.
* dom/Element.h:
* dom/Element.idl:
* testing/Internals.cpp:
* CMakeLists.txt:
* DerivedSources.make:
* WebCore.xcodeproj/project.pbxproj:
* animation/Animatable.idl:
* animation/AnimationEffect.h:
(WebCore::AnimationEffect::animation const):
(WebCore::AnimationEffect::setAnimation):
* animation/AnimationTimeline.cpp:
(WebCore::AnimationTimeline::animationWasAddedToElement):
(WebCore::AnimationTimeline::animationWasRemovedFromElement):
(WebCore::AnimationTimeline::animationsForElement):
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::animations const):
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::DocumentTimeline):
(WebCore::DocumentTimeline::detachFromDocument):
(WebCore::DocumentTimeline::currentTime):
(WebCore::DocumentTimeline::createDisplayRefreshMonitor const):
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::create):
(WebCore::WebAnimation::setEffect):
(WebCore::WebAnimation::setTimeline):
* dom/Document.cpp:
(WebCore::Document::prepareForDestruction):
(WebCore::Document::getAnimations):
* dom/Document.h:
* dom/Document.idl:
* dom/Element.cpp:
(WebCore::Element::getAnimations):
* dom/Element.h:
* dom/Element.idl:
* testing/Internals.cpp:
LayoutTests:
Update WPT expectations per new progressions and add three new tests that check the behavior of
Document.getAnimations(), Element.getAnimations() and the unique relationship between an Animation
and an AnimationEffect.
* http/wpt/web-animations/interfaces/Animatable/animate-expected.txt:
* http/wpt/web-animations/interfaces/Animatable/getAnimations-expected.txt:
* http/wpt/web-animations/interfaces/Document/getAnimations-expected.txt:
* http/wpt/wk-web-animations/interfaces/document-get-animations-expected.txt: Added.
* http/wpt/wk-web-animations/interfaces/document-get-animations.html: Added.
* http/wpt/wk-web-animations/interfaces/element-get-animations-expected.txt: Added.
* http/wpt/wk-web-animations/interfaces/element-get-animations.html: Added.
* http/wpt/wk-web-animations/timing-model/animation-effect-unique-relationship-expected.txt: Added.
* http/wpt/wk-web-animations/timing-model/animation-effect-unique-relationship.html: Added.
Canonical link: https://commits.webkit.org/195647@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@224760 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-11-13 19:14:47 +00:00
|
|
|
void detachFromDocument();
|
|
|
|
|
|
[Web Animations] Ensure CSS Transition and CSS Animation events are queued, sorted and dispatched by their timeline
https://bugs.webkit.org/show_bug.cgi?id=207364
<rdar://problem/59370413>
Reviewed by Simon Fraser.
LayoutTests/imported/w3c:
There are some progressions but also some "regressions". The progressions are real, showing the delivery of all animation events at the correct
time. However, the regressions are misleading. The fact that the "style change" tests would work was due to a design issue in the test which would
only wait one frame to detect whether a CSS Transition was started after a change made through the Web Animations API. These would work because
events were queued in the next frame, but delivered later due to the dedicated per-animation queue used, which meant the test was fooled into
thinking the CSS Transition did not start, as expected. Changing those test to use more than one frame to test for the lack of a CSS Transition
would have shown the FAIL results.
However, in order to not regress our WPT score, the issue of "style change" events will be addressed in a follow-up patch.
* web-platform-tests/css/css-transitions/CSSTransition-startTime.tentative-expected.txt:
* web-platform-tests/web-animations/interfaces/Animatable/animate-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/style-change-events-expected.txt:
* web-platform-tests/web-animations/interfaces/KeyframeEffect/style-change-events-expected.txt:
* web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt:
Source/WebCore:
Until now, AnimationPlaybackEvent events, which are new events introduced by the Web Animations spec, were enqueued in a shared queue on the DocumentTimeline
and dispatched during the "update animations and send events" procedure. However, AnimationEvent and TransitionEvent events, dispatched by CSS Animations
and CSS Transitions, were dispatched via a dedicated per-animation queue, which meant typically that those events were dispathed one runloop after the
AnimationPlaybackEvent events.
We now remove the dedicated per-animation queue and enqueue all events in the shared DocumentTimeline queue for dispatch during the "update animations and send
events" procedure. To do this correctly, we need to do a couple of other things that ensure we don't regress tests.
First, we update the DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState() to account for whether there are pending animation events,
guaranteeing that an animation update is scheduled should there be any.
Second, when animation events are enqueued in DocumentTimeline::enqueueAnimationEvent() we schedule an animation update if needed, since we know we now
have pending events that will need to be delivered in an upcoming update. We also maintain a flag between the start of the "update animations and send events"
procedure and the moment when the pending animation events queue is cleared prior to dispatching events so that events enqueued in the meantime do not
prematurely schedule animation resolution. The need for a new animation resolution will be checked at the end of the procedure.
Finally, declarative animations used to have a special suclass of WebAnimation::needsTick() that would check whether they had any pending events, ensuring
they would not be removed prematurely. We now reset a flag to false as WebAnimation::tick() is called (as part of the "update animations and send events"
procedure) and set it to true in case an animation is enqueued. This flag is then used in needsTick() to guarantee the animation is not removed before
the DocumentTimeline has had a chance to dispatch the enqueued event.
Note also that, for clarity, the DocumentTimeline::unscheduleAnimationResolution() was renamed to DocumentTimeline::clearTickScheduleTimer() since it wouldn't
actually cancel a previous animation resolution schedule.
* animation/CSSTransition.h: Fix a newly found build error due to the missing wtf/MonotonicTime.h header.
* animation/DeclarativeAnimation.cpp: Remove all code related to the dedicated per-animation queue and instead call the new WebAnimation::enqueueAnimationEvent()
method to enqueue events on the DocumentTimeline.
(WebCore::DeclarativeAnimation::DeclarativeAnimation):
(WebCore::DeclarativeAnimation::tick):
(WebCore::DeclarativeAnimation::enqueueDOMEvent):
* animation/DeclarativeAnimation.h:
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::detachFromDocument): Ensure the pending events queue is cleared when the timeline is detached from a document, ensuring that there no
longer events that would cause a ref-cycle (DocumentTimeline -> AnimationPlaybackEvent -> WebAnimation -> DocumentTimeline).
(WebCore::DocumentTimeline::suspendAnimations):
(WebCore::DocumentTimeline::removeAnimation):
(WebCore::DocumentTimeline::scheduleAnimationResolution):
(WebCore::DocumentTimeline::clearTickScheduleTimer):
(WebCore::DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState const):
(WebCore::DocumentTimeline::updateCurrentTime):
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::scheduleNextTick):
(WebCore::DocumentTimeline::animationAcceleratedRunningStateDidChange):
(WebCore::DocumentTimeline::enqueueAnimationEvent):
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::enqueueAnimationPlaybackEvent):
(WebCore::WebAnimation::enqueueAnimationEvent):
(WebCore::WebAnimation::needsTick const):
(WebCore::WebAnimation::tick):
* animation/WebAnimation.h:
LayoutTests:
Fix a couple of tests that made some incorrect assumptions.
* TestExpectations: imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html is no longer flaky.
* compositing/backing/animate-into-view.html: Because the "animationstart" event is now dispatched during the "update animations and send events" procedure, which happens
during page rendering _before_ rAF callbacks are serviced, we must remove the rAF callback used prior to adding the "animationstart" event listener or else we would never
get it and the test would time out.
* webanimations/css-transition-in-flight-reversal-accelerated.html: We must wait for the initial transition to start and then two frames before reversing the transition,
to be certain that the animation did start. Indeed, the "transitionstart" event will be fired right before the next rAF callback is called, as the animation starts in that
very same frame, and so progress will be 0 and the transition wouldn't be reversable until the next frame when the animation has progress > 0.
Canonical link: https://commits.webkit.org/220724@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256619 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-02-14 17:52:07 +00:00
|
|
|
void enqueueAnimationEvent(AnimationEventBase&);
|
requestAnimationFrame should execute before the next frame
https://bugs.webkit.org/show_bug.cgi?id=177484
Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2019-04-10
Reviewed by Simon Fraser.
LayoutTests/imported/w3c:
Add trace points for the page RenderingUpdate.
* web-platform-tests/resize-observer/resources/resizeTestHelper.js:
Change ResizeTestHelper.TIMEOUT to be 1 second instead of 100 ms which
is too short for layout tests.
Source/WebCore:
This change fixes these issues with animation timing:
1. Calling the requestAnimationFrame callbacks would have happened when
the DisplayLink fires. This may have happened even if the frame is
missed and no display is committed.
2. Style changes and layout triggered by script could trigger painting
at more than 60fps. CoreAnimation commits could happen at more than
60fps, although WindowServer will throttle those, and only some will
be shown on the screen.
This change introduces a new paint scheduling model where painting is
driven by a "RenderingUpdateScheduler", which only triggers paints once
per 16.7ms frame.
Code that previously scheduled a compositing layer flush now schedules a
"RenderingUpdate", and that update is driven by a DisplayRefreshMonitor
callback. When the render happens, we service requestAnimationFrame callbacks,
Web Animations, intersection observations and resize observations per the
"Update the rendering" step of the HTML Event Loop specification:
<https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering>.
In the future, more rendering steps will be added to this code.
* Sources.txt:
* WebCore.xcodeproj/project.pbxproj:
* accessibility/mac/AXObjectCacheMac.mm:
(WebCore::AXObjectCache::platformHandleFocusedUIElementChanged):
Fix layout tests by adding null check.
* animation/DocumentAnimationScheduler.cpp: Removed.
* animation/DocumentAnimationScheduler.h: Removed.
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::DocumentTimeline):
(WebCore::DocumentTimeline::updateThrottlingState):
(WebCore::DocumentTimeline::suspendAnimations):
(WebCore::DocumentTimeline::resumeAnimations):
(WebCore::DocumentTimeline::liveCurrentTime const):
(WebCore::DocumentTimeline::currentTime):
(WebCore::DocumentTimeline::cacheCurrentTime):
(WebCore::DocumentTimeline::animationTimingDidChange):
(WebCore::DocumentTimeline::scheduleAnimationResolution):
(WebCore::DocumentTimeline::unscheduleAnimationResolution):
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::scheduleNextTick):
(WebCore::DocumentTimeline::updateListOfElementsWithRunningAcceleratedAnimationsForElement):
Simplify this function by handling the case of no-animations separately.
(WebCore::DocumentTimeline::resolveAnimationsForElement):
Simplify the loop and delete hasPendingAcceleratedAnimations because it
is initialized to true and is not changed inside the loop.
(WebCore::DocumentTimeline::scheduleAnimationResolutionIfNeeded): Deleted.
(WebCore::DocumentTimeline::animationResolutionTimerFired): Deleted.
* animation/DocumentTimeline.h:
* dom/Document.cpp:
(WebCore::Document::resolveStyle):
There is no need to force update in resolveStyle(). notifyFlushRequired()
will be called eventually which will scheduleRenderingUpdate().
(WebCore::Document::prepareForDestruction):
(WebCore::Document::updateAnimationsAndSendEvents):
(WebCore::Document::serviceRequestAnimationFrameCallbacks):
(WebCore::Document::windowScreenDidChange):
(WebCore::Document::scheduleRenderingUpdate):
(WebCore::Document::updateIntersectionObservations):
(WebCore::Document::addResizeObserver):
(WebCore::Document::updateResizeObservations):
(WebCore::Document::scheduleForcedIntersectionObservationUpdate): Deleted.
(WebCore::Document::scheduleResizeObservations): Deleted.
(WebCore::Document::animationScheduler): Deleted.
No need to schedule web-animations, intersection observations and resize
observations updates separately. All of them will be updated through the
"Update the rendering" step, i.e. Page::updateRendering().
* dom/Document.h:
(WebCore::Document::numberOfIntersectionObservers const):
* dom/ScriptedAnimationController.cpp:
(WebCore::ScriptedAnimationController::serviceRequestAnimationFrameCallbacks):
(WebCore::ScriptedAnimationController::scheduleAnimation):
(WebCore::ScriptedAnimationController::animationTimerFired):
(WebCore::ScriptedAnimationController::serviceScriptedAnimations): Deleted.
(WebCore::ScriptedAnimationController::documentAnimationSchedulerDidFire): Deleted.
* dom/ScriptedAnimationController.h:
* page/FrameView.cpp:
(WebCore::FrameView::didLayout):
(WebCore::FrameView::viewportContentsChanged):
* page/FrameViewLayoutContext.cpp:
(WebCore::FrameViewLayoutContext::layoutTimerFired):
* page/IntersectionObserver.cpp:
(WebCore::IntersectionObserver::observe):
* page/Page.cpp:
(WebCore::Page::Page):
(WebCore::Page::layoutIfNeeded):
(WebCore::Page::updateRendering):
(WebCore::Page::renderingUpdateScheduler):
(WebCore::Page::willDisplayPage): Deleted.
(WebCore::Page::addDocumentNeedingIntersectionObservationUpdate): Deleted.
(WebCore::Page::updateIntersectionObservations): Deleted.
(WebCore::Page::scheduleForcedIntersectionObservationUpdate): Deleted.
(WebCore::Page::hasResizeObservers const): Deleted.
(WebCore::Page::gatherDocumentsNeedingResizeObservationCheck): Deleted.
(WebCore::Page::checkResizeObservations): Deleted.
(WebCore::Page::scheduleResizeObservations): Deleted.
(WebCore::Page::notifyResizeObservers): Deleted.
* page/Page.h:
(WebCore::Page::setNeedsCheckResizeObservations): Deleted.
(WebCore::Page::needsCheckResizeObservations const): Deleted.
The IntersectionObserver and the ResizeObserver do not need to schedule
their own timers. The RenderingUpdateScheduler will schedule the "Update
the rendering" step in which these obverses will be served.
* page/PageOverlayController.cpp:
(WebCore::PageOverlayController::didChangeViewExposedRect):
(WebCore::PageOverlayController::notifyFlushRequired):
Force committing the layers to be 60 fps at maximum.
* page/RenderingUpdateScheduler.cpp: Added.
(WebCore::RenderingUpdateScheduler::RenderingUpdateScheduler):
(WebCore::RenderingUpdateScheduler::scheduleRenderingUpdate):
(WebCore::RenderingUpdateScheduler::isScheduled const):
(WebCore::RenderingUpdateScheduler::startTimer):
(WebCore::RenderingUpdateScheduler::clearScheduled):
(WebCore::RenderingUpdateScheduler::createDisplayRefreshMonitor const):
(WebCore::RenderingUpdateScheduler::windowScreenDidChange):
(WebCore::RenderingUpdateScheduler::displayRefreshFired):
(WebCore::RenderingUpdateScheduler::scheduleCompositingLayerFlush):
* page/RenderingUpdateScheduler.h: Added.
(WebCore::RenderingUpdateScheduler::create):
* page/ResizeObserver.cpp:
(WebCore::ResizeObserver::observe):
(WebCore::ResizeObserver::scheduleObservations): Deleted.
* page/ResizeObserver.h:
(WebCore::ResizeObserver::hasActiveObservations const):
* page/ios/ContentChangeObserver.h:
* page/mac/ServicesOverlayController.mm:
(WebCore::ServicesOverlayController::Highlight::notifyFlushRequired):
* page/scrolling/ScrollingStateTree.cpp:
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::scheduleLayerFlushNow):
(WebCore::RenderLayerCompositor::layerTreeAsText):
Source/WebKit:
Replace the calls to Page::layoutIfNeeded() and willDisplayPage() by
a single call to Page::updateRendering(). This new function implements
"Update the rendering" step of the HTML Event Loop specification
<https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering>.
* WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:
(WebKit::DrawingAreaCoordinatedGraphics::scheduleCompositingLayerFlush):
(WebKit::DrawingAreaCoordinatedGraphics::updateBackingStoreState):
(WebKit::DrawingAreaCoordinatedGraphics::display):
* WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.cpp:
(WebKit::LayerTreeHost::layerFlushTimerFired):
* WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm:
(WebKit::RemoteLayerTreeDrawingArea::flushLayers):
-- Call Page::updateRendering() to make sure that "Update the rendering"
happens immediately before updating the page.
-- Move the call to RemoteLayerBackingStoreCollection::willFlushLayers()
to be exactly before flushing the layers. This fixes the assertion
ASSERT(m_inLayerFlush) which was firing when running a layout test.
RemoteLayerTreeDrawingArea::flushLayers() now can call itself through
TestRunner::notifyDone(). flushLayers() was calling willFlushLayers()
twice before calling didFlushLayers().
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::layoutIfNeeded):
(WebKit::WebPage::updateRendering):
(WebKit::WebPage::willDisplayPage): Deleted.
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
(WebKit::TiledCoreAnimationDrawingArea::flushLayers):
Source/WebKitLegacy/mac:
* WebView/WebView.mm:
(-[WebView _viewWillDrawInternal]):
(-[WebView _flushCompositingChanges]):
Call Page::updateRendering() which implements "Update the rendering"
step of the HTML Event Loop specification.
Source/WebKitLegacy/win:
* WebView.cpp:
(WebView::updateBackingStore):
(WebView::flushPendingGraphicsLayerChangesSoon):
(WebView::flushPendingGraphicsLayerChanges):
Call Page::updateRendering() which implements "Update the rendering"
step of the HTML Event Loop specification.
Source/WTF:
Add trace points for the page RenderingUpdate.
* wtf/SystemTracing.h:
Tools:
Add trace points for the page RenderingUpdate.
* Tracing/SystemTracePoints.plist:
LayoutTests:
* TestExpectations:
There is a slight difference between the actual DRT and the expected DRT
due to animation timing change. But these two tests are not animating
correctly if they are opened in Safari with web animation turned on.
* accessibility/mac/selection-notification-focus-change-expected.txt:
* accessibility/mac/selection-notification-focus-change.html:
Remove the debug statements form notificationCallback() since the number
of times this function is called back and the order of notifications are
not defined. This test has been flaky and some trials were made to make
it more reliable. With this change it became flaky again.
* animations/animation-multiple-callbacks-timestamp.html:
Fix variable names used by an error message.
* animations/no-style-recalc-during-accelerated-animation-expected.txt:
* animations/no-style-recalc-during-accelerated-animation.html:
One extra styleReclc was incurred due to the document styleRecalcTimer.
I think this timer is not needed anymore. I will look at removing it in
a separate patch.
* animations/resources/animation-test-helpers.js:
(waitForAnimationToStart):
The expectation that animation will start at the beginning of the next
event loop is not true anymore. The animation will start at the time the
requestAnimationFrame fires.
* compositing/video/video-clip-change-src.html:
This test loads a video data and pushes it to the encoder. Originally it
used to wait 150 ms after receiving the second canplaythrough. I had to
change this timing to 250 ms.
* css3/filters/composited-during-animation.html:
Ditto. setTimeout({...}, 0) versus requestAnimationFrame.
* media/media-controls-accessibility.html:
Updating the accessibility button happens asynchronously, see
[WebAccessibilityObjectWrapper accessibilityPerformPressAction]. Due to
changing the page update timing, this test became flaky. Originally it used
to setTimeout({...}, 10) to ensure the stringValue of the mutate button
was changed after it was pressed. The fix is to loop using rAF till the
stringValue changes.
* platform/mac-wk2/accessibility/mac/selection-notification-focus-change-expected.txt: Removed.
The number of time notificationCallback() is called and the order of
notifications are not defined. And this is why we have two expected files:
one for WK1 and the other for WK2. Since the test is now simplified, we
can get rid of this duplication. We will test the minimum reliable thing
we can test.
Canonical link: https://commits.webkit.org/211093@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244182 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-04-11 05:44:13 +00:00
|
|
|
|
[Web Animations] Coordinate "update animations and send events" procedure across multiple timelines
https://bugs.webkit.org/show_bug.cgi?id=202109
<rdar://problem/59470821>
Reviewed by Dean Jackson.
LayoutTests/imported/w3c:
Mark a new test as PASS which shows that we correctly perform a single microstask checkpoint when updating multiple timelines.
* web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt:
Source/WebCore:
So far, although we did manage multiple animation timelines per document, we mostly operated
under the assumption that there really was a single timeline. In this patch we make the
"update animations and send events" procedure, which is central to the lifecycle of animations,
work with multiple timelines such that a single microtask checkpoint is performed even with multiple
timelines, whereas we would perform one per timeline before. To do this, we move much of the logic
DocumentTimeline::updateAnimationsAndSendEvents() to DocumentTimelinesController where each step is
run across each timeline, rather than running all steps for each timeline one after the other,
respecting the single microtask checkpoint in the middle of the process.
To minimize code churn at this stage, we still keep a fair bit of logic in DocumentTimeline and,
while we remove updateAnimationsAndSendEvents(), internalUpdateAnimationsAndSendEvents() and
updateCurrentTime(), we expose three methods that allow to run the pre-flight sequence in
documentWillUpdateAnimationsAndSendEvents(), collect pending events in
prepareForPendingAnimationEventsDispatch() and run the post-flight sequence
in documentDidUpdateAnimationsAndSendEvents().
None of the logic changes, this is just moving code around. In the future, more patches will move
code from DocumentTimeline up to DocumentTimelinesController such that events are enqueued there,
and animation scheduling as well. But this already lets us pass a new test that used to flakily
reject promises in the WPT test web-animations/timing-model/timelines/update-and-send-events.html.
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::relevantAnimations const):
(WebCore::AnimationTimeline::allAnimations const):
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::documentWillUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::documentDidUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::prepareForPendingAnimationEventsDispatch):
(WebCore::DocumentTimeline::updateCurrentTime): Deleted.
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents): Deleted.
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents): Deleted.
* animation/DocumentTimeline.h:
* animation/DocumentTimelinesController.cpp:
(WebCore::DocumentTimelinesController::DocumentTimelinesController):
(WebCore::DocumentTimelinesController::updateAnimationsAndSendEvents):
* animation/DocumentTimelinesController.h:
* animation/WebAnimationTypes.h:
* dom/Document.cpp:
(WebCore::Document::ensureTimelinesController):
LayoutTests:
Remove the flaky expectation for the improved test.
* TestExpectations:
Canonical link: https://commits.webkit.org/223759@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260525 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-22 18:47:36 +00:00
|
|
|
enum class ShouldUpdateAnimationsAndSendEvents : uint8_t { Yes, No };
|
2020-05-07 21:44:13 +00:00
|
|
|
ShouldUpdateAnimationsAndSendEvents documentWillUpdateAnimationsAndSendEvents();
|
[Web Animations] Coordinate "update animations and send events" procedure across multiple timelines
https://bugs.webkit.org/show_bug.cgi?id=202109
<rdar://problem/59470821>
Reviewed by Dean Jackson.
LayoutTests/imported/w3c:
Mark a new test as PASS which shows that we correctly perform a single microstask checkpoint when updating multiple timelines.
* web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt:
Source/WebCore:
So far, although we did manage multiple animation timelines per document, we mostly operated
under the assumption that there really was a single timeline. In this patch we make the
"update animations and send events" procedure, which is central to the lifecycle of animations,
work with multiple timelines such that a single microtask checkpoint is performed even with multiple
timelines, whereas we would perform one per timeline before. To do this, we move much of the logic
DocumentTimeline::updateAnimationsAndSendEvents() to DocumentTimelinesController where each step is
run across each timeline, rather than running all steps for each timeline one after the other,
respecting the single microtask checkpoint in the middle of the process.
To minimize code churn at this stage, we still keep a fair bit of logic in DocumentTimeline and,
while we remove updateAnimationsAndSendEvents(), internalUpdateAnimationsAndSendEvents() and
updateCurrentTime(), we expose three methods that allow to run the pre-flight sequence in
documentWillUpdateAnimationsAndSendEvents(), collect pending events in
prepareForPendingAnimationEventsDispatch() and run the post-flight sequence
in documentDidUpdateAnimationsAndSendEvents().
None of the logic changes, this is just moving code around. In the future, more patches will move
code from DocumentTimeline up to DocumentTimelinesController such that events are enqueued there,
and animation scheduling as well. But this already lets us pass a new test that used to flakily
reject promises in the WPT test web-animations/timing-model/timelines/update-and-send-events.html.
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::relevantAnimations const):
(WebCore::AnimationTimeline::allAnimations const):
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::documentWillUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::documentDidUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::prepareForPendingAnimationEventsDispatch):
(WebCore::DocumentTimeline::updateCurrentTime): Deleted.
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents): Deleted.
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents): Deleted.
* animation/DocumentTimeline.h:
* animation/DocumentTimelinesController.cpp:
(WebCore::DocumentTimelinesController::DocumentTimelinesController):
(WebCore::DocumentTimelinesController::updateAnimationsAndSendEvents):
* animation/DocumentTimelinesController.h:
* animation/WebAnimationTypes.h:
* dom/Document.cpp:
(WebCore::Document::ensureTimelinesController):
LayoutTests:
Remove the flaky expectation for the improved test.
* TestExpectations:
Canonical link: https://commits.webkit.org/223759@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260525 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-22 18:47:36 +00:00
|
|
|
void removeReplacedAnimations();
|
|
|
|
|
AnimationEvents prepareForPendingAnimationEventsDispatch();
|
|
|
|
|
void documentDidUpdateAnimationsAndSendEvents();
|
2018-06-25 09:54:34 +00:00
|
|
|
|
2018-04-12 16:35:32 +00:00
|
|
|
WEBCORE_EXPORT Seconds animationInterval() const;
|
2020-05-07 21:44:13 +00:00
|
|
|
void suspendAnimations();
|
|
|
|
|
void resumeAnimations();
|
|
|
|
|
bool animationsAreSuspended() const;
|
2018-04-12 17:37:55 +00:00
|
|
|
WEBCORE_EXPORT unsigned numberOfActiveAnimationsForTesting() const;
|
2018-09-20 07:33:42 +00:00
|
|
|
WEBCORE_EXPORT Vector<std::pair<String, double>> acceleratedAnimationsForElement(Element&) const;
|
2018-09-21 11:28:40 +00:00
|
|
|
WEBCORE_EXPORT unsigned numberOfAnimationTimelineInvalidationsForTesting() const;
|
2018-04-12 16:35:32 +00:00
|
|
|
|
2017-10-20 18:41:23 +00:00
|
|
|
private:
|
2018-07-09 23:52:54 +00:00
|
|
|
DocumentTimeline(Document&, Seconds);
|
[Web Animations] Schedule animations registered on the document timeline
https://bugs.webkit.org/show_bug.cgi?id=179236
<rdar://problem/35332669>
Reviewed by Dean Jackson.
Source/WebCore:
We now schedule animations contained in the document timeline using a three-step approach.
1. Each time an object that is part of the timing model changes one of its timing properties, we call
animationTimingModelDidChange() on the document timeline. This schedules performInvalidationTask()
to be called when the current run loop completes, such that we invalidate the timing model just once
per run loop.
2. Once performInvalidationTask() is called, the timing model is invalidated in updateAnimationSchedule().
We iterate over the registered animations on the timineline and identify the shortest interval between
the current time and the next moment one of the animations requires a tick to update its value. If we
find a value below 15ms, we schedule animations to be resolved with scheduleAnimationResolution() right
away. If the value is above 15ms, and not inifinity, we schedule a one-shot timer for that interval to
call scheduleAnimationResolution().
3. Once scheduleAnimationResolution() is called, we call scheduleAnimation() on the shared DisplayRefreshMonitorManager
to be notified when the next display refresh occurs to actually resolve animations with resolveAnimations().
Note that, in this patch, resolveAnimations() does nothing, we will add support for interpolating values in
a future patch.
Another important thing to note is that every time the document timeline's current time is requested, we cache
it for the duration of the run loop such that the timing model always uses the same value during a given run loop.
Finally, to support tests where we check the state of the timing model by manually advancing time, we expose a
new pause() method on AnimationTimeline for tests to call to avoid the timeline to self-advance.
* animation/AnimationTimeline.cpp:
(WebCore::AnimationTimeline::addAnimation): Mark that the timing model changed as a result of adding an animation.
(WebCore::AnimationTimeline::removeAnimation): Mark that the timing model changed as a result of removing an animation.
(WebCore::AnimationTimeline::bindingsCurrentTime): Update the method signature to no longer be const and call into
currentTime() instead of reading directly from the m_currentTime member variable since a subclass, like DocumentTimeline,
may have a custom currentTime() implementation.
(WebCore::AnimationTimeline::setCurrentTime): Mark that the timing model changed as a result of the timeline current time
changing.
(WebCore::AnimationTimeline::bindingsCurrentTime const): Deleted.
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::currentTime): Change both methods signatures to no longer be const so that DocumentTimeline's
implementation of currentTime() may cache the current time in a member variable, enqueuing a callback when the run loop
completes for this member variable to be reset, and updating some states.
(WebCore::AnimationTimeline::pause): To be implemented by subclasses.
(WebCore::AnimationTimeline::animationTimingModelDidChange): Add a new virtual method to indicate that the timing model
needs invalidating.
(WebCore::AnimationTimeline::animations const): Add an accessor to allow animations to be accessed by a subclass.
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::create):
(WebCore::DocumentTimeline::DocumentTimeline): Update the constructor signature to receive a Document and a PlatformDisplayID
since we need a reference to the Document to get at the nowTime() and a PlatformDisplayID to create the DisplayRefreshMonitor.
(WebCore::DocumentTimeline::~DocumentTimeline): Close the task queue when the timeline gets destroyed.
(WebCore::DocumentTimeline::currentTime): If we don't have a current cahed current time, compute one and schedule
the invalidation task if needed so that we may reset the cached value as the run loop completes.
(WebCore::DocumentTimeline::pause): Allows the timeline not to self-advance, for testing purposes only.
(WebCore::DocumentTimeline::animationTimingModelDidChange): If we haven't already done so, mark that we need to update our
animation schedule in the invalidation task and schedule that task if not scheduled yet.
(WebCore::DocumentTimeline::scheduleInvalidationTaskIfNeeded): Schedule the invalidation task to run as the run loop completes
if we haven't already done so.
(WebCore::DocumentTimeline::performInvalidationTask): Update the animation schedule if needed and reset the cached current
time value.
(WebCore::DocumentTimeline::updateAnimationSchedule): Iterate over registed animations and find the shortest interval until
one of them needs to update their animation. If the shortest interval is below 15ms, schedule the animation resolution right
away. If the shortest inverval is finite and above 15ms, then schedule a one-shot timer for that interval to perform the
animation resolution then.
(WebCore::DocumentTimeline::animationScheduleTimerFired): The one-shot timer to perform the animation resolution has fired,
we call scheduleAnimationResolution().
(WebCore::DocumentTimeline::scheduleAnimationResolution): We call scheduleAnimation() on the shared DisplayRefreshMonitorManager
so that we may resolve animations on the next display refresh, or start a timer if the DisplayRefreshMonitorManager is not available.
(WebCore::DocumentTimeline::displayRefreshFired): The display is about to refresh, we call resolveAnimations().
(WebCore::DocumentTimeline::animationResolutionTimerFired): The fallback animation resolution timer has fired, we call resolveAnimations().
(WebCore::DocumentTimeline::resolveAnimations): Currently do nothing, this is where we'll iterate over registered animations to
update them with the current time.
(WebCore::DocumentTimeline::windowScreenDidChange): Notify the shared DisplayRefreshMonitorManager that the PlatformDisplayID
changed.
(WebCore::DocumentTimeline::createDisplayRefreshMonitor const): Provide a DisplayRefreshMonitor as part of the
DisplayRefreshMonitorClient protocol.
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::create): Remove extra white space.
(WebCore::WebAnimation::setStartTime): Mark that the timing model changed as a result of changing this animation's start time.
(WebCore::WebAnimation::timeToNextRequiredTick const): Compute the interval until the next time we need to resolve this animation.
If the provided current time is before this animation's start time, compute the delay until the start time. If the current time
is after the animation's start time but before the animation's end time, indicate that we want to resolve the animation again
right away and return 0ms. In any other case, return an infinite interval to indicate that we don't need to be refreshed after
the provided time.
* animation/WebAnimation.h:
* dom/Document.cpp:
(WebCore::Document::windowScreenDidChange): Notify the document timeline that the PlatformDisplayID changed.
(WebCore::Document::timeline): Provide the Document and the PlatformDisplayID to the DocumentTimeline.
* testing/Internals.cpp:
(WebCore::Internals::pauseTimeline):
* testing/Internals.h:
* testing/Internals.idl:
LayoutTests:
Adopt the new internals.pauseTimeline() method to ensure that the existing
tests do not have a self-advancing timeline since we're interested in checking
the timing model state based on manually setting the timeline current time.
Also update some WPT expectations with some progressions.
* TestExpectations: Mark two tests as flaky due to the sample time being logged
in the failure.
* http/wpt/web-animations/interfaces/AnimationTimeline/document-timeline-expected.txt:
* http/wpt/web-animations/timing-model/animations/current-time-expected.txt:
* http/wpt/web-animations/timing-model/animations/set-the-animation-start-time-expected.txt:
* http/wpt/wk-web-animations/timing-model/animation-creation-basic.html:
* http/wpt/wk-web-animations/timing-model/animation-current-time.html:
* http/wpt/wk-web-animations/timing-model/animation-effect-timing.html:
* http/wpt/wk-web-animations/timing-model/animation-effect.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-effect-property.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-start-time-property.html:
* http/wpt/wk-web-animations/timing-model/animation-playback-rate.html:
* http/wpt/wk-web-animations/timing-model/document-timeline.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect-interface-timing-duration.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect.html:
* http/wpt/wk-web-animations/timing-model/timeline-current-time.html:
Canonical link: https://commits.webkit.org/195397@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@224472 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-11-05 22:34:10 +00:00
|
|
|
|
2020-04-22 07:16:51 +00:00
|
|
|
DocumentTimelinesController* controller() const;
|
2020-03-24 17:20:33 +00:00
|
|
|
void applyPendingAcceleratedAnimations();
|
[Web Animations] Schedule animations registered on the document timeline
https://bugs.webkit.org/show_bug.cgi?id=179236
<rdar://problem/35332669>
Reviewed by Dean Jackson.
Source/WebCore:
We now schedule animations contained in the document timeline using a three-step approach.
1. Each time an object that is part of the timing model changes one of its timing properties, we call
animationTimingModelDidChange() on the document timeline. This schedules performInvalidationTask()
to be called when the current run loop completes, such that we invalidate the timing model just once
per run loop.
2. Once performInvalidationTask() is called, the timing model is invalidated in updateAnimationSchedule().
We iterate over the registered animations on the timineline and identify the shortest interval between
the current time and the next moment one of the animations requires a tick to update its value. If we
find a value below 15ms, we schedule animations to be resolved with scheduleAnimationResolution() right
away. If the value is above 15ms, and not inifinity, we schedule a one-shot timer for that interval to
call scheduleAnimationResolution().
3. Once scheduleAnimationResolution() is called, we call scheduleAnimation() on the shared DisplayRefreshMonitorManager
to be notified when the next display refresh occurs to actually resolve animations with resolveAnimations().
Note that, in this patch, resolveAnimations() does nothing, we will add support for interpolating values in
a future patch.
Another important thing to note is that every time the document timeline's current time is requested, we cache
it for the duration of the run loop such that the timing model always uses the same value during a given run loop.
Finally, to support tests where we check the state of the timing model by manually advancing time, we expose a
new pause() method on AnimationTimeline for tests to call to avoid the timeline to self-advance.
* animation/AnimationTimeline.cpp:
(WebCore::AnimationTimeline::addAnimation): Mark that the timing model changed as a result of adding an animation.
(WebCore::AnimationTimeline::removeAnimation): Mark that the timing model changed as a result of removing an animation.
(WebCore::AnimationTimeline::bindingsCurrentTime): Update the method signature to no longer be const and call into
currentTime() instead of reading directly from the m_currentTime member variable since a subclass, like DocumentTimeline,
may have a custom currentTime() implementation.
(WebCore::AnimationTimeline::setCurrentTime): Mark that the timing model changed as a result of the timeline current time
changing.
(WebCore::AnimationTimeline::bindingsCurrentTime const): Deleted.
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::currentTime): Change both methods signatures to no longer be const so that DocumentTimeline's
implementation of currentTime() may cache the current time in a member variable, enqueuing a callback when the run loop
completes for this member variable to be reset, and updating some states.
(WebCore::AnimationTimeline::pause): To be implemented by subclasses.
(WebCore::AnimationTimeline::animationTimingModelDidChange): Add a new virtual method to indicate that the timing model
needs invalidating.
(WebCore::AnimationTimeline::animations const): Add an accessor to allow animations to be accessed by a subclass.
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::create):
(WebCore::DocumentTimeline::DocumentTimeline): Update the constructor signature to receive a Document and a PlatformDisplayID
since we need a reference to the Document to get at the nowTime() and a PlatformDisplayID to create the DisplayRefreshMonitor.
(WebCore::DocumentTimeline::~DocumentTimeline): Close the task queue when the timeline gets destroyed.
(WebCore::DocumentTimeline::currentTime): If we don't have a current cahed current time, compute one and schedule
the invalidation task if needed so that we may reset the cached value as the run loop completes.
(WebCore::DocumentTimeline::pause): Allows the timeline not to self-advance, for testing purposes only.
(WebCore::DocumentTimeline::animationTimingModelDidChange): If we haven't already done so, mark that we need to update our
animation schedule in the invalidation task and schedule that task if not scheduled yet.
(WebCore::DocumentTimeline::scheduleInvalidationTaskIfNeeded): Schedule the invalidation task to run as the run loop completes
if we haven't already done so.
(WebCore::DocumentTimeline::performInvalidationTask): Update the animation schedule if needed and reset the cached current
time value.
(WebCore::DocumentTimeline::updateAnimationSchedule): Iterate over registed animations and find the shortest interval until
one of them needs to update their animation. If the shortest interval is below 15ms, schedule the animation resolution right
away. If the shortest inverval is finite and above 15ms, then schedule a one-shot timer for that interval to perform the
animation resolution then.
(WebCore::DocumentTimeline::animationScheduleTimerFired): The one-shot timer to perform the animation resolution has fired,
we call scheduleAnimationResolution().
(WebCore::DocumentTimeline::scheduleAnimationResolution): We call scheduleAnimation() on the shared DisplayRefreshMonitorManager
so that we may resolve animations on the next display refresh, or start a timer if the DisplayRefreshMonitorManager is not available.
(WebCore::DocumentTimeline::displayRefreshFired): The display is about to refresh, we call resolveAnimations().
(WebCore::DocumentTimeline::animationResolutionTimerFired): The fallback animation resolution timer has fired, we call resolveAnimations().
(WebCore::DocumentTimeline::resolveAnimations): Currently do nothing, this is where we'll iterate over registered animations to
update them with the current time.
(WebCore::DocumentTimeline::windowScreenDidChange): Notify the shared DisplayRefreshMonitorManager that the PlatformDisplayID
changed.
(WebCore::DocumentTimeline::createDisplayRefreshMonitor const): Provide a DisplayRefreshMonitor as part of the
DisplayRefreshMonitorClient protocol.
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::create): Remove extra white space.
(WebCore::WebAnimation::setStartTime): Mark that the timing model changed as a result of changing this animation's start time.
(WebCore::WebAnimation::timeToNextRequiredTick const): Compute the interval until the next time we need to resolve this animation.
If the provided current time is before this animation's start time, compute the delay until the start time. If the current time
is after the animation's start time but before the animation's end time, indicate that we want to resolve the animation again
right away and return 0ms. In any other case, return an infinite interval to indicate that we don't need to be refreshed after
the provided time.
* animation/WebAnimation.h:
* dom/Document.cpp:
(WebCore::Document::windowScreenDidChange): Notify the document timeline that the PlatformDisplayID changed.
(WebCore::Document::timeline): Provide the Document and the PlatformDisplayID to the DocumentTimeline.
* testing/Internals.cpp:
(WebCore::Internals::pauseTimeline):
* testing/Internals.h:
* testing/Internals.idl:
LayoutTests:
Adopt the new internals.pauseTimeline() method to ensure that the existing
tests do not have a self-advancing timeline since we're interested in checking
the timing model state based on manually setting the timeline current time.
Also update some WPT expectations with some progressions.
* TestExpectations: Mark two tests as flaky due to the sample time being logged
in the failure.
* http/wpt/web-animations/interfaces/AnimationTimeline/document-timeline-expected.txt:
* http/wpt/web-animations/timing-model/animations/current-time-expected.txt:
* http/wpt/web-animations/timing-model/animations/set-the-animation-start-time-expected.txt:
* http/wpt/wk-web-animations/timing-model/animation-creation-basic.html:
* http/wpt/wk-web-animations/timing-model/animation-current-time.html:
* http/wpt/wk-web-animations/timing-model/animation-effect-timing.html:
* http/wpt/wk-web-animations/timing-model/animation-effect.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-effect-property.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-start-time-property.html:
* http/wpt/wk-web-animations/timing-model/animation-playback-rate.html:
* http/wpt/wk-web-animations/timing-model/document-timeline.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect-interface-timing-duration.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect.html:
* http/wpt/wk-web-animations/timing-model/timeline-current-time.html:
Canonical link: https://commits.webkit.org/195397@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@224472 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-11-05 22:34:10 +00:00
|
|
|
void scheduleInvalidationTaskIfNeeded();
|
|
|
|
|
void scheduleAnimationResolution();
|
[Web Animations] Ensure CSS Transition and CSS Animation events are queued, sorted and dispatched by their timeline
https://bugs.webkit.org/show_bug.cgi?id=207364
<rdar://problem/59370413>
Reviewed by Simon Fraser.
LayoutTests/imported/w3c:
There are some progressions but also some "regressions". The progressions are real, showing the delivery of all animation events at the correct
time. However, the regressions are misleading. The fact that the "style change" tests would work was due to a design issue in the test which would
only wait one frame to detect whether a CSS Transition was started after a change made through the Web Animations API. These would work because
events were queued in the next frame, but delivered later due to the dedicated per-animation queue used, which meant the test was fooled into
thinking the CSS Transition did not start, as expected. Changing those test to use more than one frame to test for the lack of a CSS Transition
would have shown the FAIL results.
However, in order to not regress our WPT score, the issue of "style change" events will be addressed in a follow-up patch.
* web-platform-tests/css/css-transitions/CSSTransition-startTime.tentative-expected.txt:
* web-platform-tests/web-animations/interfaces/Animatable/animate-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/style-change-events-expected.txt:
* web-platform-tests/web-animations/interfaces/KeyframeEffect/style-change-events-expected.txt:
* web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt:
Source/WebCore:
Until now, AnimationPlaybackEvent events, which are new events introduced by the Web Animations spec, were enqueued in a shared queue on the DocumentTimeline
and dispatched during the "update animations and send events" procedure. However, AnimationEvent and TransitionEvent events, dispatched by CSS Animations
and CSS Transitions, were dispatched via a dedicated per-animation queue, which meant typically that those events were dispathed one runloop after the
AnimationPlaybackEvent events.
We now remove the dedicated per-animation queue and enqueue all events in the shared DocumentTimeline queue for dispatch during the "update animations and send
events" procedure. To do this correctly, we need to do a couple of other things that ensure we don't regress tests.
First, we update the DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState() to account for whether there are pending animation events,
guaranteeing that an animation update is scheduled should there be any.
Second, when animation events are enqueued in DocumentTimeline::enqueueAnimationEvent() we schedule an animation update if needed, since we know we now
have pending events that will need to be delivered in an upcoming update. We also maintain a flag between the start of the "update animations and send events"
procedure and the moment when the pending animation events queue is cleared prior to dispatching events so that events enqueued in the meantime do not
prematurely schedule animation resolution. The need for a new animation resolution will be checked at the end of the procedure.
Finally, declarative animations used to have a special suclass of WebAnimation::needsTick() that would check whether they had any pending events, ensuring
they would not be removed prematurely. We now reset a flag to false as WebAnimation::tick() is called (as part of the "update animations and send events"
procedure) and set it to true in case an animation is enqueued. This flag is then used in needsTick() to guarantee the animation is not removed before
the DocumentTimeline has had a chance to dispatch the enqueued event.
Note also that, for clarity, the DocumentTimeline::unscheduleAnimationResolution() was renamed to DocumentTimeline::clearTickScheduleTimer() since it wouldn't
actually cancel a previous animation resolution schedule.
* animation/CSSTransition.h: Fix a newly found build error due to the missing wtf/MonotonicTime.h header.
* animation/DeclarativeAnimation.cpp: Remove all code related to the dedicated per-animation queue and instead call the new WebAnimation::enqueueAnimationEvent()
method to enqueue events on the DocumentTimeline.
(WebCore::DeclarativeAnimation::DeclarativeAnimation):
(WebCore::DeclarativeAnimation::tick):
(WebCore::DeclarativeAnimation::enqueueDOMEvent):
* animation/DeclarativeAnimation.h:
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::detachFromDocument): Ensure the pending events queue is cleared when the timeline is detached from a document, ensuring that there no
longer events that would cause a ref-cycle (DocumentTimeline -> AnimationPlaybackEvent -> WebAnimation -> DocumentTimeline).
(WebCore::DocumentTimeline::suspendAnimations):
(WebCore::DocumentTimeline::removeAnimation):
(WebCore::DocumentTimeline::scheduleAnimationResolution):
(WebCore::DocumentTimeline::clearTickScheduleTimer):
(WebCore::DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState const):
(WebCore::DocumentTimeline::updateCurrentTime):
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::scheduleNextTick):
(WebCore::DocumentTimeline::animationAcceleratedRunningStateDidChange):
(WebCore::DocumentTimeline::enqueueAnimationEvent):
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::enqueueAnimationPlaybackEvent):
(WebCore::WebAnimation::enqueueAnimationEvent):
(WebCore::WebAnimation::needsTick const):
(WebCore::WebAnimation::tick):
* animation/WebAnimation.h:
LayoutTests:
Fix a couple of tests that made some incorrect assumptions.
* TestExpectations: imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html is no longer flaky.
* compositing/backing/animate-into-view.html: Because the "animationstart" event is now dispatched during the "update animations and send events" procedure, which happens
during page rendering _before_ rAF callbacks are serviced, we must remove the rAF callback used prior to adding the "animationstart" event listener or else we would never
get it and the test would time out.
* webanimations/css-transition-in-flight-reversal-accelerated.html: We must wait for the initial transition to start and then two frames before reversing the transition,
to be certain that the animation did start. Indeed, the "transitionstart" event will be fired right before the next rAF callback is called, as the animation starts in that
very same frame, and so progress will be 0 and the transition wouldn't be reversable until the next frame when the animation has progress > 0.
Canonical link: https://commits.webkit.org/220724@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256619 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-02-14 17:52:07 +00:00
|
|
|
void clearTickScheduleTimer();
|
requestAnimationFrame should execute before the next frame
https://bugs.webkit.org/show_bug.cgi?id=177484
Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2019-04-10
Reviewed by Simon Fraser.
LayoutTests/imported/w3c:
Add trace points for the page RenderingUpdate.
* web-platform-tests/resize-observer/resources/resizeTestHelper.js:
Change ResizeTestHelper.TIMEOUT to be 1 second instead of 100 ms which
is too short for layout tests.
Source/WebCore:
This change fixes these issues with animation timing:
1. Calling the requestAnimationFrame callbacks would have happened when
the DisplayLink fires. This may have happened even if the frame is
missed and no display is committed.
2. Style changes and layout triggered by script could trigger painting
at more than 60fps. CoreAnimation commits could happen at more than
60fps, although WindowServer will throttle those, and only some will
be shown on the screen.
This change introduces a new paint scheduling model where painting is
driven by a "RenderingUpdateScheduler", which only triggers paints once
per 16.7ms frame.
Code that previously scheduled a compositing layer flush now schedules a
"RenderingUpdate", and that update is driven by a DisplayRefreshMonitor
callback. When the render happens, we service requestAnimationFrame callbacks,
Web Animations, intersection observations and resize observations per the
"Update the rendering" step of the HTML Event Loop specification:
<https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering>.
In the future, more rendering steps will be added to this code.
* Sources.txt:
* WebCore.xcodeproj/project.pbxproj:
* accessibility/mac/AXObjectCacheMac.mm:
(WebCore::AXObjectCache::platformHandleFocusedUIElementChanged):
Fix layout tests by adding null check.
* animation/DocumentAnimationScheduler.cpp: Removed.
* animation/DocumentAnimationScheduler.h: Removed.
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::DocumentTimeline):
(WebCore::DocumentTimeline::updateThrottlingState):
(WebCore::DocumentTimeline::suspendAnimations):
(WebCore::DocumentTimeline::resumeAnimations):
(WebCore::DocumentTimeline::liveCurrentTime const):
(WebCore::DocumentTimeline::currentTime):
(WebCore::DocumentTimeline::cacheCurrentTime):
(WebCore::DocumentTimeline::animationTimingDidChange):
(WebCore::DocumentTimeline::scheduleAnimationResolution):
(WebCore::DocumentTimeline::unscheduleAnimationResolution):
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::scheduleNextTick):
(WebCore::DocumentTimeline::updateListOfElementsWithRunningAcceleratedAnimationsForElement):
Simplify this function by handling the case of no-animations separately.
(WebCore::DocumentTimeline::resolveAnimationsForElement):
Simplify the loop and delete hasPendingAcceleratedAnimations because it
is initialized to true and is not changed inside the loop.
(WebCore::DocumentTimeline::scheduleAnimationResolutionIfNeeded): Deleted.
(WebCore::DocumentTimeline::animationResolutionTimerFired): Deleted.
* animation/DocumentTimeline.h:
* dom/Document.cpp:
(WebCore::Document::resolveStyle):
There is no need to force update in resolveStyle(). notifyFlushRequired()
will be called eventually which will scheduleRenderingUpdate().
(WebCore::Document::prepareForDestruction):
(WebCore::Document::updateAnimationsAndSendEvents):
(WebCore::Document::serviceRequestAnimationFrameCallbacks):
(WebCore::Document::windowScreenDidChange):
(WebCore::Document::scheduleRenderingUpdate):
(WebCore::Document::updateIntersectionObservations):
(WebCore::Document::addResizeObserver):
(WebCore::Document::updateResizeObservations):
(WebCore::Document::scheduleForcedIntersectionObservationUpdate): Deleted.
(WebCore::Document::scheduleResizeObservations): Deleted.
(WebCore::Document::animationScheduler): Deleted.
No need to schedule web-animations, intersection observations and resize
observations updates separately. All of them will be updated through the
"Update the rendering" step, i.e. Page::updateRendering().
* dom/Document.h:
(WebCore::Document::numberOfIntersectionObservers const):
* dom/ScriptedAnimationController.cpp:
(WebCore::ScriptedAnimationController::serviceRequestAnimationFrameCallbacks):
(WebCore::ScriptedAnimationController::scheduleAnimation):
(WebCore::ScriptedAnimationController::animationTimerFired):
(WebCore::ScriptedAnimationController::serviceScriptedAnimations): Deleted.
(WebCore::ScriptedAnimationController::documentAnimationSchedulerDidFire): Deleted.
* dom/ScriptedAnimationController.h:
* page/FrameView.cpp:
(WebCore::FrameView::didLayout):
(WebCore::FrameView::viewportContentsChanged):
* page/FrameViewLayoutContext.cpp:
(WebCore::FrameViewLayoutContext::layoutTimerFired):
* page/IntersectionObserver.cpp:
(WebCore::IntersectionObserver::observe):
* page/Page.cpp:
(WebCore::Page::Page):
(WebCore::Page::layoutIfNeeded):
(WebCore::Page::updateRendering):
(WebCore::Page::renderingUpdateScheduler):
(WebCore::Page::willDisplayPage): Deleted.
(WebCore::Page::addDocumentNeedingIntersectionObservationUpdate): Deleted.
(WebCore::Page::updateIntersectionObservations): Deleted.
(WebCore::Page::scheduleForcedIntersectionObservationUpdate): Deleted.
(WebCore::Page::hasResizeObservers const): Deleted.
(WebCore::Page::gatherDocumentsNeedingResizeObservationCheck): Deleted.
(WebCore::Page::checkResizeObservations): Deleted.
(WebCore::Page::scheduleResizeObservations): Deleted.
(WebCore::Page::notifyResizeObservers): Deleted.
* page/Page.h:
(WebCore::Page::setNeedsCheckResizeObservations): Deleted.
(WebCore::Page::needsCheckResizeObservations const): Deleted.
The IntersectionObserver and the ResizeObserver do not need to schedule
their own timers. The RenderingUpdateScheduler will schedule the "Update
the rendering" step in which these obverses will be served.
* page/PageOverlayController.cpp:
(WebCore::PageOverlayController::didChangeViewExposedRect):
(WebCore::PageOverlayController::notifyFlushRequired):
Force committing the layers to be 60 fps at maximum.
* page/RenderingUpdateScheduler.cpp: Added.
(WebCore::RenderingUpdateScheduler::RenderingUpdateScheduler):
(WebCore::RenderingUpdateScheduler::scheduleRenderingUpdate):
(WebCore::RenderingUpdateScheduler::isScheduled const):
(WebCore::RenderingUpdateScheduler::startTimer):
(WebCore::RenderingUpdateScheduler::clearScheduled):
(WebCore::RenderingUpdateScheduler::createDisplayRefreshMonitor const):
(WebCore::RenderingUpdateScheduler::windowScreenDidChange):
(WebCore::RenderingUpdateScheduler::displayRefreshFired):
(WebCore::RenderingUpdateScheduler::scheduleCompositingLayerFlush):
* page/RenderingUpdateScheduler.h: Added.
(WebCore::RenderingUpdateScheduler::create):
* page/ResizeObserver.cpp:
(WebCore::ResizeObserver::observe):
(WebCore::ResizeObserver::scheduleObservations): Deleted.
* page/ResizeObserver.h:
(WebCore::ResizeObserver::hasActiveObservations const):
* page/ios/ContentChangeObserver.h:
* page/mac/ServicesOverlayController.mm:
(WebCore::ServicesOverlayController::Highlight::notifyFlushRequired):
* page/scrolling/ScrollingStateTree.cpp:
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::scheduleLayerFlushNow):
(WebCore::RenderLayerCompositor::layerTreeAsText):
Source/WebKit:
Replace the calls to Page::layoutIfNeeded() and willDisplayPage() by
a single call to Page::updateRendering(). This new function implements
"Update the rendering" step of the HTML Event Loop specification
<https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering>.
* WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:
(WebKit::DrawingAreaCoordinatedGraphics::scheduleCompositingLayerFlush):
(WebKit::DrawingAreaCoordinatedGraphics::updateBackingStoreState):
(WebKit::DrawingAreaCoordinatedGraphics::display):
* WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.cpp:
(WebKit::LayerTreeHost::layerFlushTimerFired):
* WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm:
(WebKit::RemoteLayerTreeDrawingArea::flushLayers):
-- Call Page::updateRendering() to make sure that "Update the rendering"
happens immediately before updating the page.
-- Move the call to RemoteLayerBackingStoreCollection::willFlushLayers()
to be exactly before flushing the layers. This fixes the assertion
ASSERT(m_inLayerFlush) which was firing when running a layout test.
RemoteLayerTreeDrawingArea::flushLayers() now can call itself through
TestRunner::notifyDone(). flushLayers() was calling willFlushLayers()
twice before calling didFlushLayers().
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::layoutIfNeeded):
(WebKit::WebPage::updateRendering):
(WebKit::WebPage::willDisplayPage): Deleted.
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
(WebKit::TiledCoreAnimationDrawingArea::flushLayers):
Source/WebKitLegacy/mac:
* WebView/WebView.mm:
(-[WebView _viewWillDrawInternal]):
(-[WebView _flushCompositingChanges]):
Call Page::updateRendering() which implements "Update the rendering"
step of the HTML Event Loop specification.
Source/WebKitLegacy/win:
* WebView.cpp:
(WebView::updateBackingStore):
(WebView::flushPendingGraphicsLayerChangesSoon):
(WebView::flushPendingGraphicsLayerChanges):
Call Page::updateRendering() which implements "Update the rendering"
step of the HTML Event Loop specification.
Source/WTF:
Add trace points for the page RenderingUpdate.
* wtf/SystemTracing.h:
Tools:
Add trace points for the page RenderingUpdate.
* Tracing/SystemTracePoints.plist:
LayoutTests:
* TestExpectations:
There is a slight difference between the actual DRT and the expected DRT
due to animation timing change. But these two tests are not animating
correctly if they are opened in Safari with web animation turned on.
* accessibility/mac/selection-notification-focus-change-expected.txt:
* accessibility/mac/selection-notification-focus-change.html:
Remove the debug statements form notificationCallback() since the number
of times this function is called back and the order of notifications are
not defined. This test has been flaky and some trials were made to make
it more reliable. With this change it became flaky again.
* animations/animation-multiple-callbacks-timestamp.html:
Fix variable names used by an error message.
* animations/no-style-recalc-during-accelerated-animation-expected.txt:
* animations/no-style-recalc-during-accelerated-animation.html:
One extra styleReclc was incurred due to the document styleRecalcTimer.
I think this timer is not needed anymore. I will look at removing it in
a separate patch.
* animations/resources/animation-test-helpers.js:
(waitForAnimationToStart):
The expectation that animation will start at the beginning of the next
event loop is not true anymore. The animation will start at the time the
requestAnimationFrame fires.
* compositing/video/video-clip-change-src.html:
This test loads a video data and pushes it to the encoder. Originally it
used to wait 150 ms after receiving the second canplaythrough. I had to
change this timing to 250 ms.
* css3/filters/composited-during-animation.html:
Ditto. setTimeout({...}, 0) versus requestAnimationFrame.
* media/media-controls-accessibility.html:
Updating the accessibility button happens asynchronously, see
[WebAccessibilityObjectWrapper accessibilityPerformPressAction]. Due to
changing the page update timing, this test became flaky. Originally it used
to setTimeout({...}, 10) to ensure the stringValue of the mutate button
was changed after it was pressed. The fix is to loop using rAF till the
stringValue changes.
* platform/mac-wk2/accessibility/mac/selection-notification-focus-change-expected.txt: Removed.
The number of time notificationCallback() is called and the order of
notifications are not defined. And this is why we have two expected files:
one for WK1 and the other for WK2. Since the test is now simplified, we
can get rid of this duplication. We will test the minimum reliable thing
we can test.
Canonical link: https://commits.webkit.org/211093@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244182 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-04-11 05:44:13 +00:00
|
|
|
void internalUpdateAnimationsAndSendEvents();
|
[Web Animations] Don't schedule animation frames or update style while an accelerated animation is running
https://bugs.webkit.org/show_bug.cgi?id=191542
<rdar://problem/45356027>
Reviewed by Simon Fraser.
Source/WebCore:
Test: animations/no-style-recalc-during-accelerated-animation.html
In order to be more power-efficient, we stop scheduling calls to updateAnimationsAndSendEvents() when running only accelerated
animations. To do that, we prevent scheduling further animation resolution if we're in the process of updating animations, and
when we are done, call the new DocumentTimeline::scheduleNextTick() method that will check whether we have only accelerated
animations running, and in that case check which of those animations needs an update the soonest and starts a timer scheduled
for that time when we'll schedule animation resolution.
By default, animations compute the time until their natural completion but in the case of CSS Animations, we want to make sure
we also update animations in-flight to dispatch "animationiteration" events.
* animation/AnimationEffect.h: Make the simpleIterationProgress() public so it can be called by WebAnimation::timeToNextTick().
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::DocumentTimeline): Create the m_tickScheduleTimer and set it up to call scheduleAnimationResolutionIfNeeded().
(WebCore::DocumentTimeline::suspendAnimations): If we don't already have a cached current time, cache the current time.
(WebCore::DocumentTimeline::resumeAnimations): Reset the cached current time to ensure we'll get a fresh one when updating animations next.
(WebCore::DocumentTimeline::liveCurrentTime const): Factor the code to compute the current time out of currentTime() so that we can
cache the current time in suspendAnimations() without also automatically clearing the current time.
(WebCore::DocumentTimeline::currentTime): Use liveCurrentTime() and cacheCurrentTime() since much of the code from this function has been
factored out into those. Additionally, we were failing to clear the current time if called inside an animation frame, which we now do correctly
by virtue of using cacheCurrentTime(). This fixes some flakiness.
(WebCore::DocumentTimeline::cacheCurrentTime): Factor the code to cache the current time out of currentTime().
(WebCore::DocumentTimeline::maybeClearCachedCurrentTime): No need to clear the current time if we get suspended.
(WebCore::DocumentTimeline::scheduleAnimationResolutionIfNeeded): Prevent scheduling an animation update if we're in the middle of one already,
scheduleNextTick() will be called after animations are updated to see if we should schedule an animation update instead.
(WebCore::DocumentTimeline::unscheduleAnimationResolution): Cancel the m_tickScheduleTimer if we need to unschedule animation resolution.
(WebCore::DocumentTimeline::animationResolutionTimerFired): Factor the call to applyPendingAcceleratedAnimations() out of updateAnimationsAndSendEvents()
and call scheduleNextTick().
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents): Set the new m_isUpdatingAnimations member variable to true while this function is running.
(WebCore::DocumentTimeline::scheduleNextTick): Schedule an animation update immediately if we have any relevant animation that is not accelerated.
Otherwise, iterate through all animations to figure out the earliest moment at which we need to update animations.
(WebCore::DocumentTimeline::updateListOfElementsWithRunningAcceleratedAnimationsForElement): Use the new WebAnimation::isRunningAccelerated() function.
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::isRunningAccelerated const): Since we end up checking if an animation is running with an accelerated effect, we introduce a new
function to get that information directly through the WebAnimation object without bothering about its effect.
(WebCore::WebAnimation::resolve): We should only call updateFinishedState() here since timingDidChange() would also notify the timeline about a potential
change in relevance, which is not necessary and which would schedule an animation frame even for animations that are accelerated.
(WebCore::WebAnimation::timeToNextTick const): Compute the time until our animation completion or, in the case of CSS animations, the next iteration.
* animation/WebAnimation.h:
LayoutTests:
Add a test that checks that we make only minimal style updates and still dispatch events while an accelerated animation is running.
* animations/no-style-recalc-during-accelerated-animation-expected.txt: Added.
* animations/no-style-recalc-during-accelerated-animation.html: Added.
* fast/layers/no-clipping-overflow-hidden-added-after-transform-expected.html:
* fast/layers/no-clipping-overflow-hidden-added-after-transform.html: Change the colors to avoid a tiny ImageOnlyFailure.
* platform/win/TestExpectations: Mark some regressions tracked by webkit.org/b/191584.
Canonical link: https://commits.webkit.org/206337@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@238128 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-11-13 10:22:56 +00:00
|
|
|
void scheduleNextTick();
|
2019-10-02 18:30:04 +00:00
|
|
|
bool animationCanBeRemoved(WebAnimation&);
|
2019-11-16 17:11:44 +00:00
|
|
|
bool shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState() const;
|
[Web Animations] Schedule animations registered on the document timeline
https://bugs.webkit.org/show_bug.cgi?id=179236
<rdar://problem/35332669>
Reviewed by Dean Jackson.
Source/WebCore:
We now schedule animations contained in the document timeline using a three-step approach.
1. Each time an object that is part of the timing model changes one of its timing properties, we call
animationTimingModelDidChange() on the document timeline. This schedules performInvalidationTask()
to be called when the current run loop completes, such that we invalidate the timing model just once
per run loop.
2. Once performInvalidationTask() is called, the timing model is invalidated in updateAnimationSchedule().
We iterate over the registered animations on the timineline and identify the shortest interval between
the current time and the next moment one of the animations requires a tick to update its value. If we
find a value below 15ms, we schedule animations to be resolved with scheduleAnimationResolution() right
away. If the value is above 15ms, and not inifinity, we schedule a one-shot timer for that interval to
call scheduleAnimationResolution().
3. Once scheduleAnimationResolution() is called, we call scheduleAnimation() on the shared DisplayRefreshMonitorManager
to be notified when the next display refresh occurs to actually resolve animations with resolveAnimations().
Note that, in this patch, resolveAnimations() does nothing, we will add support for interpolating values in
a future patch.
Another important thing to note is that every time the document timeline's current time is requested, we cache
it for the duration of the run loop such that the timing model always uses the same value during a given run loop.
Finally, to support tests where we check the state of the timing model by manually advancing time, we expose a
new pause() method on AnimationTimeline for tests to call to avoid the timeline to self-advance.
* animation/AnimationTimeline.cpp:
(WebCore::AnimationTimeline::addAnimation): Mark that the timing model changed as a result of adding an animation.
(WebCore::AnimationTimeline::removeAnimation): Mark that the timing model changed as a result of removing an animation.
(WebCore::AnimationTimeline::bindingsCurrentTime): Update the method signature to no longer be const and call into
currentTime() instead of reading directly from the m_currentTime member variable since a subclass, like DocumentTimeline,
may have a custom currentTime() implementation.
(WebCore::AnimationTimeline::setCurrentTime): Mark that the timing model changed as a result of the timeline current time
changing.
(WebCore::AnimationTimeline::bindingsCurrentTime const): Deleted.
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::currentTime): Change both methods signatures to no longer be const so that DocumentTimeline's
implementation of currentTime() may cache the current time in a member variable, enqueuing a callback when the run loop
completes for this member variable to be reset, and updating some states.
(WebCore::AnimationTimeline::pause): To be implemented by subclasses.
(WebCore::AnimationTimeline::animationTimingModelDidChange): Add a new virtual method to indicate that the timing model
needs invalidating.
(WebCore::AnimationTimeline::animations const): Add an accessor to allow animations to be accessed by a subclass.
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::create):
(WebCore::DocumentTimeline::DocumentTimeline): Update the constructor signature to receive a Document and a PlatformDisplayID
since we need a reference to the Document to get at the nowTime() and a PlatformDisplayID to create the DisplayRefreshMonitor.
(WebCore::DocumentTimeline::~DocumentTimeline): Close the task queue when the timeline gets destroyed.
(WebCore::DocumentTimeline::currentTime): If we don't have a current cahed current time, compute one and schedule
the invalidation task if needed so that we may reset the cached value as the run loop completes.
(WebCore::DocumentTimeline::pause): Allows the timeline not to self-advance, for testing purposes only.
(WebCore::DocumentTimeline::animationTimingModelDidChange): If we haven't already done so, mark that we need to update our
animation schedule in the invalidation task and schedule that task if not scheduled yet.
(WebCore::DocumentTimeline::scheduleInvalidationTaskIfNeeded): Schedule the invalidation task to run as the run loop completes
if we haven't already done so.
(WebCore::DocumentTimeline::performInvalidationTask): Update the animation schedule if needed and reset the cached current
time value.
(WebCore::DocumentTimeline::updateAnimationSchedule): Iterate over registed animations and find the shortest interval until
one of them needs to update their animation. If the shortest interval is below 15ms, schedule the animation resolution right
away. If the shortest inverval is finite and above 15ms, then schedule a one-shot timer for that interval to perform the
animation resolution then.
(WebCore::DocumentTimeline::animationScheduleTimerFired): The one-shot timer to perform the animation resolution has fired,
we call scheduleAnimationResolution().
(WebCore::DocumentTimeline::scheduleAnimationResolution): We call scheduleAnimation() on the shared DisplayRefreshMonitorManager
so that we may resolve animations on the next display refresh, or start a timer if the DisplayRefreshMonitorManager is not available.
(WebCore::DocumentTimeline::displayRefreshFired): The display is about to refresh, we call resolveAnimations().
(WebCore::DocumentTimeline::animationResolutionTimerFired): The fallback animation resolution timer has fired, we call resolveAnimations().
(WebCore::DocumentTimeline::resolveAnimations): Currently do nothing, this is where we'll iterate over registered animations to
update them with the current time.
(WebCore::DocumentTimeline::windowScreenDidChange): Notify the shared DisplayRefreshMonitorManager that the PlatformDisplayID
changed.
(WebCore::DocumentTimeline::createDisplayRefreshMonitor const): Provide a DisplayRefreshMonitor as part of the
DisplayRefreshMonitorClient protocol.
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::create): Remove extra white space.
(WebCore::WebAnimation::setStartTime): Mark that the timing model changed as a result of changing this animation's start time.
(WebCore::WebAnimation::timeToNextRequiredTick const): Compute the interval until the next time we need to resolve this animation.
If the provided current time is before this animation's start time, compute the delay until the start time. If the current time
is after the animation's start time but before the animation's end time, indicate that we want to resolve the animation again
right away and return 0ms. In any other case, return an infinite interval to indicate that we don't need to be refreshed after
the provided time.
* animation/WebAnimation.h:
* dom/Document.cpp:
(WebCore::Document::windowScreenDidChange): Notify the document timeline that the PlatformDisplayID changed.
(WebCore::Document::timeline): Provide the Document and the PlatformDisplayID to the DocumentTimeline.
* testing/Internals.cpp:
(WebCore::Internals::pauseTimeline):
* testing/Internals.h:
* testing/Internals.idl:
LayoutTests:
Adopt the new internals.pauseTimeline() method to ensure that the existing
tests do not have a self-advancing timeline since we're interested in checking
the timing model state based on manually setting the timeline current time.
Also update some WPT expectations with some progressions.
* TestExpectations: Mark two tests as flaky due to the sample time being logged
in the failure.
* http/wpt/web-animations/interfaces/AnimationTimeline/document-timeline-expected.txt:
* http/wpt/web-animations/timing-model/animations/current-time-expected.txt:
* http/wpt/web-animations/timing-model/animations/set-the-animation-start-time-expected.txt:
* http/wpt/wk-web-animations/timing-model/animation-creation-basic.html:
* http/wpt/wk-web-animations/timing-model/animation-current-time.html:
* http/wpt/wk-web-animations/timing-model/animation-effect-timing.html:
* http/wpt/wk-web-animations/timing-model/animation-effect.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-effect-property.html:
* http/wpt/wk-web-animations/timing-model/animation-interface-start-time-property.html:
* http/wpt/wk-web-animations/timing-model/animation-playback-rate.html:
* http/wpt/wk-web-animations/timing-model/document-timeline.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect-interface-timing-duration.html:
* http/wpt/wk-web-animations/timing-model/keyframe-effect.html:
* http/wpt/wk-web-animations/timing-model/timeline-current-time.html:
Canonical link: https://commits.webkit.org/195397@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@224472 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-11-05 22:34:10 +00:00
|
|
|
|
2019-01-10 08:19:39 +00:00
|
|
|
Timer m_tickScheduleTimer;
|
|
|
|
|
HashSet<RefPtr<WebAnimation>> m_acceleratedAnimationsPendingRunningStateChange;
|
[Web Animations] Coordinate "update animations and send events" procedure across multiple timelines
https://bugs.webkit.org/show_bug.cgi?id=202109
<rdar://problem/59470821>
Reviewed by Dean Jackson.
LayoutTests/imported/w3c:
Mark a new test as PASS which shows that we correctly perform a single microstask checkpoint when updating multiple timelines.
* web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt:
Source/WebCore:
So far, although we did manage multiple animation timelines per document, we mostly operated
under the assumption that there really was a single timeline. In this patch we make the
"update animations and send events" procedure, which is central to the lifecycle of animations,
work with multiple timelines such that a single microtask checkpoint is performed even with multiple
timelines, whereas we would perform one per timeline before. To do this, we move much of the logic
DocumentTimeline::updateAnimationsAndSendEvents() to DocumentTimelinesController where each step is
run across each timeline, rather than running all steps for each timeline one after the other,
respecting the single microtask checkpoint in the middle of the process.
To minimize code churn at this stage, we still keep a fair bit of logic in DocumentTimeline and,
while we remove updateAnimationsAndSendEvents(), internalUpdateAnimationsAndSendEvents() and
updateCurrentTime(), we expose three methods that allow to run the pre-flight sequence in
documentWillUpdateAnimationsAndSendEvents(), collect pending events in
prepareForPendingAnimationEventsDispatch() and run the post-flight sequence
in documentDidUpdateAnimationsAndSendEvents().
None of the logic changes, this is just moving code around. In the future, more patches will move
code from DocumentTimeline up to DocumentTimelinesController such that events are enqueued there,
and animation scheduling as well. But this already lets us pass a new test that used to flakily
reject promises in the WPT test web-animations/timing-model/timelines/update-and-send-events.html.
* animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::relevantAnimations const):
(WebCore::AnimationTimeline::allAnimations const):
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::documentWillUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::documentDidUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::prepareForPendingAnimationEventsDispatch):
(WebCore::DocumentTimeline::updateCurrentTime): Deleted.
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents): Deleted.
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents): Deleted.
* animation/DocumentTimeline.h:
* animation/DocumentTimelinesController.cpp:
(WebCore::DocumentTimelinesController::DocumentTimelinesController):
(WebCore::DocumentTimelinesController::updateAnimationsAndSendEvents):
* animation/DocumentTimelinesController.h:
* animation/WebAnimationTypes.h:
* dom/Document.cpp:
(WebCore::Document::ensureTimelinesController):
LayoutTests:
Remove the flaky expectation for the improved test.
* TestExpectations:
Canonical link: https://commits.webkit.org/223759@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260525 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-22 18:47:36 +00:00
|
|
|
AnimationEvents m_pendingAnimationEvents;
|
2020-02-24 20:28:23 +00:00
|
|
|
WeakPtr<Document> m_document;
|
2018-07-09 23:52:54 +00:00
|
|
|
Seconds m_originTime;
|
2019-01-10 08:19:39 +00:00
|
|
|
unsigned m_numberOfAnimationTimelineInvalidationsForTesting { 0 };
|
requestAnimationFrame should execute before the next frame
https://bugs.webkit.org/show_bug.cgi?id=177484
Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2019-04-10
Reviewed by Simon Fraser.
LayoutTests/imported/w3c:
Add trace points for the page RenderingUpdate.
* web-platform-tests/resize-observer/resources/resizeTestHelper.js:
Change ResizeTestHelper.TIMEOUT to be 1 second instead of 100 ms which
is too short for layout tests.
Source/WebCore:
This change fixes these issues with animation timing:
1. Calling the requestAnimationFrame callbacks would have happened when
the DisplayLink fires. This may have happened even if the frame is
missed and no display is committed.
2. Style changes and layout triggered by script could trigger painting
at more than 60fps. CoreAnimation commits could happen at more than
60fps, although WindowServer will throttle those, and only some will
be shown on the screen.
This change introduces a new paint scheduling model where painting is
driven by a "RenderingUpdateScheduler", which only triggers paints once
per 16.7ms frame.
Code that previously scheduled a compositing layer flush now schedules a
"RenderingUpdate", and that update is driven by a DisplayRefreshMonitor
callback. When the render happens, we service requestAnimationFrame callbacks,
Web Animations, intersection observations and resize observations per the
"Update the rendering" step of the HTML Event Loop specification:
<https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering>.
In the future, more rendering steps will be added to this code.
* Sources.txt:
* WebCore.xcodeproj/project.pbxproj:
* accessibility/mac/AXObjectCacheMac.mm:
(WebCore::AXObjectCache::platformHandleFocusedUIElementChanged):
Fix layout tests by adding null check.
* animation/DocumentAnimationScheduler.cpp: Removed.
* animation/DocumentAnimationScheduler.h: Removed.
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::DocumentTimeline):
(WebCore::DocumentTimeline::updateThrottlingState):
(WebCore::DocumentTimeline::suspendAnimations):
(WebCore::DocumentTimeline::resumeAnimations):
(WebCore::DocumentTimeline::liveCurrentTime const):
(WebCore::DocumentTimeline::currentTime):
(WebCore::DocumentTimeline::cacheCurrentTime):
(WebCore::DocumentTimeline::animationTimingDidChange):
(WebCore::DocumentTimeline::scheduleAnimationResolution):
(WebCore::DocumentTimeline::unscheduleAnimationResolution):
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::scheduleNextTick):
(WebCore::DocumentTimeline::updateListOfElementsWithRunningAcceleratedAnimationsForElement):
Simplify this function by handling the case of no-animations separately.
(WebCore::DocumentTimeline::resolveAnimationsForElement):
Simplify the loop and delete hasPendingAcceleratedAnimations because it
is initialized to true and is not changed inside the loop.
(WebCore::DocumentTimeline::scheduleAnimationResolutionIfNeeded): Deleted.
(WebCore::DocumentTimeline::animationResolutionTimerFired): Deleted.
* animation/DocumentTimeline.h:
* dom/Document.cpp:
(WebCore::Document::resolveStyle):
There is no need to force update in resolveStyle(). notifyFlushRequired()
will be called eventually which will scheduleRenderingUpdate().
(WebCore::Document::prepareForDestruction):
(WebCore::Document::updateAnimationsAndSendEvents):
(WebCore::Document::serviceRequestAnimationFrameCallbacks):
(WebCore::Document::windowScreenDidChange):
(WebCore::Document::scheduleRenderingUpdate):
(WebCore::Document::updateIntersectionObservations):
(WebCore::Document::addResizeObserver):
(WebCore::Document::updateResizeObservations):
(WebCore::Document::scheduleForcedIntersectionObservationUpdate): Deleted.
(WebCore::Document::scheduleResizeObservations): Deleted.
(WebCore::Document::animationScheduler): Deleted.
No need to schedule web-animations, intersection observations and resize
observations updates separately. All of them will be updated through the
"Update the rendering" step, i.e. Page::updateRendering().
* dom/Document.h:
(WebCore::Document::numberOfIntersectionObservers const):
* dom/ScriptedAnimationController.cpp:
(WebCore::ScriptedAnimationController::serviceRequestAnimationFrameCallbacks):
(WebCore::ScriptedAnimationController::scheduleAnimation):
(WebCore::ScriptedAnimationController::animationTimerFired):
(WebCore::ScriptedAnimationController::serviceScriptedAnimations): Deleted.
(WebCore::ScriptedAnimationController::documentAnimationSchedulerDidFire): Deleted.
* dom/ScriptedAnimationController.h:
* page/FrameView.cpp:
(WebCore::FrameView::didLayout):
(WebCore::FrameView::viewportContentsChanged):
* page/FrameViewLayoutContext.cpp:
(WebCore::FrameViewLayoutContext::layoutTimerFired):
* page/IntersectionObserver.cpp:
(WebCore::IntersectionObserver::observe):
* page/Page.cpp:
(WebCore::Page::Page):
(WebCore::Page::layoutIfNeeded):
(WebCore::Page::updateRendering):
(WebCore::Page::renderingUpdateScheduler):
(WebCore::Page::willDisplayPage): Deleted.
(WebCore::Page::addDocumentNeedingIntersectionObservationUpdate): Deleted.
(WebCore::Page::updateIntersectionObservations): Deleted.
(WebCore::Page::scheduleForcedIntersectionObservationUpdate): Deleted.
(WebCore::Page::hasResizeObservers const): Deleted.
(WebCore::Page::gatherDocumentsNeedingResizeObservationCheck): Deleted.
(WebCore::Page::checkResizeObservations): Deleted.
(WebCore::Page::scheduleResizeObservations): Deleted.
(WebCore::Page::notifyResizeObservers): Deleted.
* page/Page.h:
(WebCore::Page::setNeedsCheckResizeObservations): Deleted.
(WebCore::Page::needsCheckResizeObservations const): Deleted.
The IntersectionObserver and the ResizeObserver do not need to schedule
their own timers. The RenderingUpdateScheduler will schedule the "Update
the rendering" step in which these obverses will be served.
* page/PageOverlayController.cpp:
(WebCore::PageOverlayController::didChangeViewExposedRect):
(WebCore::PageOverlayController::notifyFlushRequired):
Force committing the layers to be 60 fps at maximum.
* page/RenderingUpdateScheduler.cpp: Added.
(WebCore::RenderingUpdateScheduler::RenderingUpdateScheduler):
(WebCore::RenderingUpdateScheduler::scheduleRenderingUpdate):
(WebCore::RenderingUpdateScheduler::isScheduled const):
(WebCore::RenderingUpdateScheduler::startTimer):
(WebCore::RenderingUpdateScheduler::clearScheduled):
(WebCore::RenderingUpdateScheduler::createDisplayRefreshMonitor const):
(WebCore::RenderingUpdateScheduler::windowScreenDidChange):
(WebCore::RenderingUpdateScheduler::displayRefreshFired):
(WebCore::RenderingUpdateScheduler::scheduleCompositingLayerFlush):
* page/RenderingUpdateScheduler.h: Added.
(WebCore::RenderingUpdateScheduler::create):
* page/ResizeObserver.cpp:
(WebCore::ResizeObserver::observe):
(WebCore::ResizeObserver::scheduleObservations): Deleted.
* page/ResizeObserver.h:
(WebCore::ResizeObserver::hasActiveObservations const):
* page/ios/ContentChangeObserver.h:
* page/mac/ServicesOverlayController.mm:
(WebCore::ServicesOverlayController::Highlight::notifyFlushRequired):
* page/scrolling/ScrollingStateTree.cpp:
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::scheduleLayerFlushNow):
(WebCore::RenderLayerCompositor::layerTreeAsText):
Source/WebKit:
Replace the calls to Page::layoutIfNeeded() and willDisplayPage() by
a single call to Page::updateRendering(). This new function implements
"Update the rendering" step of the HTML Event Loop specification
<https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering>.
* WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:
(WebKit::DrawingAreaCoordinatedGraphics::scheduleCompositingLayerFlush):
(WebKit::DrawingAreaCoordinatedGraphics::updateBackingStoreState):
(WebKit::DrawingAreaCoordinatedGraphics::display):
* WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.cpp:
(WebKit::LayerTreeHost::layerFlushTimerFired):
* WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm:
(WebKit::RemoteLayerTreeDrawingArea::flushLayers):
-- Call Page::updateRendering() to make sure that "Update the rendering"
happens immediately before updating the page.
-- Move the call to RemoteLayerBackingStoreCollection::willFlushLayers()
to be exactly before flushing the layers. This fixes the assertion
ASSERT(m_inLayerFlush) which was firing when running a layout test.
RemoteLayerTreeDrawingArea::flushLayers() now can call itself through
TestRunner::notifyDone(). flushLayers() was calling willFlushLayers()
twice before calling didFlushLayers().
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::layoutIfNeeded):
(WebKit::WebPage::updateRendering):
(WebKit::WebPage::willDisplayPage): Deleted.
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
(WebKit::TiledCoreAnimationDrawingArea::flushLayers):
Source/WebKitLegacy/mac:
* WebView/WebView.mm:
(-[WebView _viewWillDrawInternal]):
(-[WebView _flushCompositingChanges]):
Call Page::updateRendering() which implements "Update the rendering"
step of the HTML Event Loop specification.
Source/WebKitLegacy/win:
* WebView.cpp:
(WebView::updateBackingStore):
(WebView::flushPendingGraphicsLayerChangesSoon):
(WebView::flushPendingGraphicsLayerChanges):
Call Page::updateRendering() which implements "Update the rendering"
step of the HTML Event Loop specification.
Source/WTF:
Add trace points for the page RenderingUpdate.
* wtf/SystemTracing.h:
Tools:
Add trace points for the page RenderingUpdate.
* Tracing/SystemTracePoints.plist:
LayoutTests:
* TestExpectations:
There is a slight difference between the actual DRT and the expected DRT
due to animation timing change. But these two tests are not animating
correctly if they are opened in Safari with web animation turned on.
* accessibility/mac/selection-notification-focus-change-expected.txt:
* accessibility/mac/selection-notification-focus-change.html:
Remove the debug statements form notificationCallback() since the number
of times this function is called back and the order of notifications are
not defined. This test has been flaky and some trials were made to make
it more reliable. With this change it became flaky again.
* animations/animation-multiple-callbacks-timestamp.html:
Fix variable names used by an error message.
* animations/no-style-recalc-during-accelerated-animation-expected.txt:
* animations/no-style-recalc-during-accelerated-animation.html:
One extra styleReclc was incurred due to the document styleRecalcTimer.
I think this timer is not needed anymore. I will look at removing it in
a separate patch.
* animations/resources/animation-test-helpers.js:
(waitForAnimationToStart):
The expectation that animation will start at the beginning of the next
event loop is not true anymore. The animation will start at the time the
requestAnimationFrame fires.
* compositing/video/video-clip-change-src.html:
This test loads a video data and pushes it to the encoder. Originally it
used to wait 150 ms after receiving the second canplaythrough. I had to
change this timing to 250 ms.
* css3/filters/composited-during-animation.html:
Ditto. setTimeout({...}, 0) versus requestAnimationFrame.
* media/media-controls-accessibility.html:
Updating the accessibility button happens asynchronously, see
[WebAccessibilityObjectWrapper accessibilityPerformPressAction]. Due to
changing the page update timing, this test became flaky. Originally it used
to setTimeout({...}, 10) to ensure the stringValue of the mutate button
was changed after it was pressed. The fix is to loop using rAF till the
stringValue changes.
* platform/mac-wk2/accessibility/mac/selection-notification-focus-change-expected.txt: Removed.
The number of time notificationCallback() is called and the order of
notifications are not defined. And this is why we have two expected files:
one for WK1 and the other for WK2. Since the test is now simplified, we
can get rid of this duplication. We will test the minimum reliable thing
we can test.
Canonical link: https://commits.webkit.org/211093@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244182 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-04-11 05:44:13 +00:00
|
|
|
bool m_animationResolutionScheduled { false };
|
[Web Animations] Ensure CSS Transition and CSS Animation events are queued, sorted and dispatched by their timeline
https://bugs.webkit.org/show_bug.cgi?id=207364
<rdar://problem/59370413>
Reviewed by Simon Fraser.
LayoutTests/imported/w3c:
There are some progressions but also some "regressions". The progressions are real, showing the delivery of all animation events at the correct
time. However, the regressions are misleading. The fact that the "style change" tests would work was due to a design issue in the test which would
only wait one frame to detect whether a CSS Transition was started after a change made through the Web Animations API. These would work because
events were queued in the next frame, but delivered later due to the dedicated per-animation queue used, which meant the test was fooled into
thinking the CSS Transition did not start, as expected. Changing those test to use more than one frame to test for the lack of a CSS Transition
would have shown the FAIL results.
However, in order to not regress our WPT score, the issue of "style change" events will be addressed in a follow-up patch.
* web-platform-tests/css/css-transitions/CSSTransition-startTime.tentative-expected.txt:
* web-platform-tests/web-animations/interfaces/Animatable/animate-expected.txt:
* web-platform-tests/web-animations/interfaces/Animation/style-change-events-expected.txt:
* web-platform-tests/web-animations/interfaces/KeyframeEffect/style-change-events-expected.txt:
* web-platform-tests/web-animations/timing-model/timelines/update-and-send-events-expected.txt:
Source/WebCore:
Until now, AnimationPlaybackEvent events, which are new events introduced by the Web Animations spec, were enqueued in a shared queue on the DocumentTimeline
and dispatched during the "update animations and send events" procedure. However, AnimationEvent and TransitionEvent events, dispatched by CSS Animations
and CSS Transitions, were dispatched via a dedicated per-animation queue, which meant typically that those events were dispathed one runloop after the
AnimationPlaybackEvent events.
We now remove the dedicated per-animation queue and enqueue all events in the shared DocumentTimeline queue for dispatch during the "update animations and send
events" procedure. To do this correctly, we need to do a couple of other things that ensure we don't regress tests.
First, we update the DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState() to account for whether there are pending animation events,
guaranteeing that an animation update is scheduled should there be any.
Second, when animation events are enqueued in DocumentTimeline::enqueueAnimationEvent() we schedule an animation update if needed, since we know we now
have pending events that will need to be delivered in an upcoming update. We also maintain a flag between the start of the "update animations and send events"
procedure and the moment when the pending animation events queue is cleared prior to dispatching events so that events enqueued in the meantime do not
prematurely schedule animation resolution. The need for a new animation resolution will be checked at the end of the procedure.
Finally, declarative animations used to have a special suclass of WebAnimation::needsTick() that would check whether they had any pending events, ensuring
they would not be removed prematurely. We now reset a flag to false as WebAnimation::tick() is called (as part of the "update animations and send events"
procedure) and set it to true in case an animation is enqueued. This flag is then used in needsTick() to guarantee the animation is not removed before
the DocumentTimeline has had a chance to dispatch the enqueued event.
Note also that, for clarity, the DocumentTimeline::unscheduleAnimationResolution() was renamed to DocumentTimeline::clearTickScheduleTimer() since it wouldn't
actually cancel a previous animation resolution schedule.
* animation/CSSTransition.h: Fix a newly found build error due to the missing wtf/MonotonicTime.h header.
* animation/DeclarativeAnimation.cpp: Remove all code related to the dedicated per-animation queue and instead call the new WebAnimation::enqueueAnimationEvent()
method to enqueue events on the DocumentTimeline.
(WebCore::DeclarativeAnimation::DeclarativeAnimation):
(WebCore::DeclarativeAnimation::tick):
(WebCore::DeclarativeAnimation::enqueueDOMEvent):
* animation/DeclarativeAnimation.h:
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::detachFromDocument): Ensure the pending events queue is cleared when the timeline is detached from a document, ensuring that there no
longer events that would cause a ref-cycle (DocumentTimeline -> AnimationPlaybackEvent -> WebAnimation -> DocumentTimeline).
(WebCore::DocumentTimeline::suspendAnimations):
(WebCore::DocumentTimeline::removeAnimation):
(WebCore::DocumentTimeline::scheduleAnimationResolution):
(WebCore::DocumentTimeline::clearTickScheduleTimer):
(WebCore::DocumentTimeline::shouldRunUpdateAnimationsAndSendEventsIgnoringSuspensionState const):
(WebCore::DocumentTimeline::updateCurrentTime):
(WebCore::DocumentTimeline::updateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::internalUpdateAnimationsAndSendEvents):
(WebCore::DocumentTimeline::scheduleNextTick):
(WebCore::DocumentTimeline::animationAcceleratedRunningStateDidChange):
(WebCore::DocumentTimeline::enqueueAnimationEvent):
* animation/DocumentTimeline.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::enqueueAnimationPlaybackEvent):
(WebCore::WebAnimation::enqueueAnimationEvent):
(WebCore::WebAnimation::needsTick const):
(WebCore::WebAnimation::tick):
* animation/WebAnimation.h:
LayoutTests:
Fix a couple of tests that made some incorrect assumptions.
* TestExpectations: imported/w3c/web-platform-tests/web-animations/timing-model/timelines/update-and-send-events.html is no longer flaky.
* compositing/backing/animate-into-view.html: Because the "animationstart" event is now dispatched during the "update animations and send events" procedure, which happens
during page rendering _before_ rAF callbacks are serviced, we must remove the rAF callback used prior to adding the "animationstart" event listener or else we would never
get it and the test would time out.
* webanimations/css-transition-in-flight-reversal-accelerated.html: We must wait for the initial transition to start and then two frames before reversing the transition,
to be certain that the animation did start. Indeed, the "transitionstart" event will be fired right before the next rAF callback is called, as the animation starts in that
very same frame, and so progress will be 0 and the transition wouldn't be reversable until the next frame when the animation has progress > 0.
Canonical link: https://commits.webkit.org/220724@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@256619 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-02-14 17:52:07 +00:00
|
|
|
bool m_shouldScheduleAnimationResolutionForNewPendingEvents { true };
|
2017-10-20 18:41:23 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
} // namespace WebCore
|
|
|
|
|
|
|
|
|
|
SPECIALIZE_TYPE_TRAITS_ANIMATION_TIMELINE(DocumentTimeline, isDocumentTimeline())
|