Now that we don't actually start pending animations until the following refresh
driver tick we no longer need to be able to fast-forward the AnimationTimeline
between ticks.
When a player is made pending, we rely on it being added to a pending player
tracker that will eventually start the player. However, there are a few
situations where this might not happen. For example, we can't find a pending
player tracker (e.g. there's no source content or the source content isn't
attached to a document), or the pending player tracker disappeared.
In these cases we still want to ensure that such a player does actually get
started. This patch attempts to detect such situations and start players
accordingly.
There are, unfortunately, currently no tests for this. I have been unsuccessful
in recreating any of the situations these tests are supposed to cover.
This patch switches on the new, "actually start the player in the next refresh
driver tick" behavior. It updates PendingPlayerTracker, adding
a StartPendingPlayersOnNextTick method which calls the appropriate method on
AnimationPlayer. The existing StartPendingPlayers is renamed to
StartPendingPlayersNow and is used for testing only.
Furthermore, since we now expect AnimationPlayer::StartOnNextTick to be
functional, AnimationPlayer::DoPlay is updated to use it when there is no
document available. This should make playing an animation player always
asynchronous, that is, always transition to the pending state temporarily
(unless we are already playing).
Earlier in this patch series we added AnimationPlayer::StartOnNextTick which
takes a ready time parameter expressed in timeline time. In order to call this
method when painting finishes we need to convert the TimeStamp recorded when
painting finished to a timeline time. However, when the timeline is driven by
a refresh driver under test control we can no longer meaningfully do this
conversion since there is no correspondence between the notion of time used to
record the time when painting finished (wallclock time) and the notion of time
used by the timeline (which has been arbitrarily adjusted by test code).
We need a way to detect this situation so that we know not to call
ToTimelineTime in that case.
Alternatively, we could make ToTimelineTime automatically return a null value
when its refresh driver is under test control. However, in this situation
ToTimelineTime can still actually be used to convert a TimeStamp to a timeline
time as long as the TimeStamp is from the same refresh driver. Indeed,
GetCurrentTime does exactly that. So if we were to go down that route we would
have to provide a way for GetCurrentTime to work around that restriction.
For now, this patch puts the onus on the caller of ToTimelineTime to check if
the timeline is under test control first (unless they are passing a TimeStamp
from the same refresh driver, in which case there is no need to check).
This patch makes AnimationPlayer act on requests to StartOnNextTick by checking
for mPendingReadyTime on each tick.
We also check that the ready time is not in the future since currently it might
be possible that we get multiple calls to AnimationPlayer::Tick within a single
refresh driver tick.
Note that this patch shouldn't actually produce any observable change yet,
however, since we don't call StartOnNextTick anywhere.
Adds a method that schedules an animation player to begin on the next tick using
the supplied time as the start time.
We don't call this yet, however, but simply add the method and the
mPendingReadyTime member it sets.
In addition to AnimationPlayer::StartNow, this patch series also makes
AnimationPlayer::Tick start animations.
Since these methods will share a lot of code we first factor out a common
ResumeAt method to encapsulate the common code.
In this patch series we adjust the behavior of animation starting so that the
animation does not actually start until the following refresh driver tick. This
requires some tweaks to tests to ensure they continue to pass.
This patch adds a test that we correctly incorporate the delay when setting
a layer animation's initialCurrentTime.
The notion of 'current time' on layer animations differs from that on main
thread animations in that it does not incorporate the animation delay.
Instead, we wait until an animation's delay has complete before putting it
on the layer and then it we add without delay.
For animations that are still waiting to start we need to factor this delay into
the initialCurrentTime stored on the layer animation so that when we update
the animation's start time it represents the time *after* the delay has
finished. Previously we failed to do this but no tests failed since all existing
tests for delay rely on DOMWindowUtils.advanceTimeAndRefresh which avoids this
particular code path (since we don't add pending animations to layers while
the refresh driver is under test control).
This patch adds a test for animation delay that does not rely on
DOMWindowUtils.advanceTimeAndRefresh which has been confirmed to fail if we
don't incorporate the delay in our calculation of initialCurrentTime.
This patch (finally!) introduces the delayed start behavior. It updates
AnimationPlayer::DoPlay to put animations in the PendingPlayerTracker from
where they are triggered.
This patch also updates nsTransitionManager to set the animation's source
before calling Play as otherwise the AnimationPlayer won't be able to access
the pending player tracker (which it locates by navigating AnimationPlayer ->
Animation (source content) -> target element -> composed doc -> pending player
tracker). In future, when we support setting the AnimationPlayer.source property
we will make this more robust so that the order in which these steps are
performed doesn't matter.
This patch also updates a couple of tests to reflect the fact that
AnimationPlayer will now return the pending state.
This patch adds a test that we correctly incorporate the delay when setting
a layer animation's initialCurrentTime.
The notion of 'current time' on layer animations differs from that on main
thread animations in that it does not incorporate the animation delay.
Instead, we wait until an animation's delay has complete before putting it
on the layer and then it we add without delay.
For animations that are still waiting to start we need to factor this delay into
the initialCurrentTime stored on the layer animation so that when we update
the animation's start time it represents the time *after* the delay has
finished. Previously we failed to do this but no tests failed since all existing
tests for delay rely on DOMWindowUtils.advanceTimeAndRefresh which avoids this
particular code path (since we don't add pending animations to layers while
the refresh driver is under test control).
This patch adds a test for animation delay that does not rely on
DOMWindowUtils.advanceTimeAndRefresh which has been confirmed to fail if we
don't incorporate the delay in our calculation of initialCurrentTime.
This patch (finally!) introduces the delayed start behavior. It updates
AnimationPlayer::DoPlay to put animations in the PendingPlayerTracker from
where they are triggered.
This patch also updates nsTransitionManager to set the animation's source
before calling Play as otherwise the AnimationPlayer won't be able to access
the pending player tracker (which it locates by navigating AnimationPlayer ->
Animation (source content) -> target element -> composed doc -> pending player
tracker). In future, when we support setting the AnimationPlayer.source property
we will make this more robust so that the order in which these steps are
performed doesn't matter.
This patch also updates a couple of tests to reflect the fact that
AnimationPlayer will now return the pending state.
In the future we will want to specifically just update source content without
necessarily triggering any other actions that might take place on a tick (like
queuing events).
We want to time animations from when their first frame is painted. However,
interruptible reflow complicates this since, for a given set of pending
animations, some may be painted whilst others are not. To simplify this we
simply force an uninterruptible reflow when we have animations that are
waiting to start.
We would like to trigger animations from the point when the first frame of the
animation is painted. However, some animations will never trigger a paint (e.g.
animations with an empty keyframes rule). These animations should start start
however. To ensure this, whenever an animation is newly pending we schedule
a paint.
This patch adds a reference from PendingPlayerTracker back to the document
object that owns it. This is used in the next patch in this series to find the
document's root frame for scheduling a paint.
Normally animation players get times from their timeline which is based on the
refresh driver for their associated document. However, for animations that
we time from when their first frame has been rendered, we want to record the
actual time when painting finished as their start time. If we wait until the
next refresh driver tick then the delay between playing an animation and its
actual start will be too great.
In this patch, we introduce a mechanism for fast-forwarding a timeline to a
time between the current refresh driver time and the next refresh driver tick.
By adjusting the timeline rather than the player we maintain a consistent state
(in fact, if we just naively set the animation player start time to the
timestamp value we recorded when painting finished it will appear to start in
the future and the animation will temporarily jump from playing, to waiting to
start, then back to playing again on the next refresh driver tick).
To be completely consistent, however, when we fast-forward the timeline we
should tell all animation players listening to the timeline to mark their
target element as needing a style flush. Otherwise we may be able to observe an
inconsistency between some animation players' current time and the computed
style of their targets.
We don't, however, currently know which players are observing a given timeline.
We will likely introduce that in the near future (in order to implement
AnimationTimeline.getAnimationPlayers) and fix the inconsistency in timing then.
A test later in the patch series verifies this inconsistency so it is easy to
fix in future.
An alternative approach would be to simply record the time when animation should
start, send that time to the compositor but don't actually update the animation
start time on the main thread until the subsequent refresh driver tick. Such
an approach is complex as it introduces an additional state--"finished pending
but not yet started". We will attempt to switch to that approach in bug 1112480.
ResolveStartTime is a bit hard to understand. Eventually, once we implement
SetStartTime, we can probably remove this method altogether and just use that.
This renaming moves us closer to that direction.
This patch also adjusts a comment about the preconditions for calling StartNow.
This is because in a subsequent patch in this series we will update the
assertion at the beginning of StartNow to simply check that the player is
pending.
This patch adds a means of terminating an animation so that is has no effect.
The procedure is defined by Web Animations:
http://w3c.github.io/web-animations/#cancelling-a-player-section
We don't implement all of this, however, since we don't currently support the
finished promise or custom effects.
In a later bug we will expose this as the cancel() method on AnimationPlayer.
We call this method for terminated animations in nsAnimationManager and
nsTransitionManager to ensure they get removed from the pending player tracker
and so that, for example, the ready promise of CSS Animation player objects is
rejected when the corresponding item is removed from animation-name.
In Bug 1104435 we made the initial ready promise be created lazily. This patch
takes this a step further and makes sure we don't create the promise at all
unless it is explicitly requested.
This patch updates the pause procedure for AnimationPlayer so that if there is
a pending play it will be cancelled.
At the same it removes the existing check for a redundant call to Pause when we
are already paused. This check is not necessary since if we are already paused
the method will have no effect anyway.
Finally, this patch updates the comment about going to the pending state while
pausing since this will happen in bug 1109390.
This patch adds a member for tracking if a player is currently pending or not
and uses this to return the "pending" state from PlayState(). We don't currently
set mIsPending to true yet, however.
Additionally, this patch updates AnimationPlayer::ComposeStyle to set
aNeedsRefreshes to true when the player is pending. This is used by the
appropriate animation/transition manager to determine if it should continue to
observe the refresh driver or not.
This patch adds a hashtable to nsDocument that stores all the animation players
that are currently waiting to start. In the future it may also be used to store
players that are waiting to pause which is why the methods are called
AddPlayPending/RemovePlayPending instead of just AddPlayer/RemovePlayer.
AnimationPlayer.ready will currently always be resolved but by updating these
tests to wait on it anyway they should continue to work once we introduce the
delayed animation start behavior.
Since bug 1104433, step_func now passes on the return value of its callback.
That means we can use it directly as a Promise callback function in Promise
chains where the return value of the function is another Promise.
This patch updates existing tests to eliminate the awkward handling we had
around wrapping some parts of Promise callbacks in step() but leaving the return
statement outside it.
This patch moves commonly used addDiv and waitForFrame test methods to
a separate testcommon.js support file.
It also takes advantage of the updates to testharness.js from bug 1104433 to
rework addDiv such that it automatically removes the created div at the end of
the test.
Every time we call play() (and in future pause()) we should create a new Promise
object and then fulfill it when we complete the play() operation.
This patch adds that step. This allows us to tweak test cases that currently
expect animations to start immediately so that by waiting on this promise they
will continue to work when we introduce the delayed start behavior in bug
927349.
We should also resolve the ready promise when we are in the pending state and
pause() is called. However, since we currently never enter the pending state we
don't need to add this just yet.
