After starting layer animations we set the same start time on content
animations but we don't apply it until the next tick (see bug 1112480 for
background). However, in some circumstances, we can end up creating layer
animations again within the same refresh driver tick. In this case, we should
initialize the animations with the same start time as we previously used.
This patch exposes the pending start time set on content animations so that,
if set, we can use it when building layer animations.
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.
Web Animations defines the AnimationPlayer.ready Promise as type
Promise<AnimationPlayer>. This promise resolves to the AnimationPlayer object on
which it is defined. However, in order to be able to pass AnimationPlayer as
a resolution value it needs to implement nsISupports.
This patch makes AnimationPlayer derive from nsISupports.
In order to create a Promise object for AnimationPlayer.ready, we need an
nsIGlobalObject. Currently we can access this through the following chain:
AnimationPlayer -> AnimationTimeline -> Document -> nsIGlobalObject
Come bug 1096776 (Support AnimationPlayers without a timeline or with an
inactive timeline) we will no longer be able to rely on having an
AnimationTimeline so we will probably have to store the corresponding window
object on the AnimationPlayer. For now, however, we can look up the timeline as
above.
This patch makes this a little more straightforward by changing the return type
and value of AnimationTimeline::GetParentObject to return the nsIGlobalObject of
the document with which it is associated.
In preparation for deferring the start of animations in bug 927349, this patch
makes the code that resolves the start time a separate method. In this patch we
call the method immediately from AnimationPlayer::DoPlay. However, in the future
this will be called at a later point when the first frame of the animation has
been rendered.
Now that there is a public accessor for mStartTime, we can make it a protected
member of AnimationPlayer. The only time mStartTime is ever set is when playing
the animation so we can replace external modifications to mStartTime with calls
to Play(). This simplifies implementing deferred starting of animations
in bug 927349 by isolating the deferred playback logic to AnimationPlayer.
Note that even when we call PauseFromStyle immediately afterwards we still need
to call PlayFromStyle (or Play) first in order to resolve the time at which the
player should be paused. A newly created player doesn't have a current time so
if we were simply to call pause it wouldn't pause at the start of the animation
as we might expect. The call to Play(FromStyle) will cause the current time to
become zero and then we pause at that time.
In forthcoming patches we will encapsulate AnimationPlayer::mStartTime so we can
ensure that related state is updated appropriately. We would like to expose
mStartTime via GetStartTime() but currently a method of that name returns the
start time as a double.
This patch applies the pattern used for currentTime to startTime; specifically,
GetCurrentTime() returns the TimeDuration (since that's what C++ callers should
use) while GetCurrentTimeAsDouble() returns a double.
At the same time, this patch also removes the [Pure] extended attribute from
startTime in the WebIDL definition since subsequent patches either in this bug
or in bug 927349 will mean that startTime can be updated out-of-band.
Specifically, we will implement deferred playback of animation such that the
startTime remains null until we've finished rendering the first frame of the
animation.
This patch reworks AnimationPlayer to represent the paused state by a null start
time. This brings it into line with recent changes in the Web Animations spec
and removes the need for the mIsPaused member variable.
The idea is that in order for a player to play, it needs a start time and
an active timeline. The processing is roughly:
* If it is seeked to a particular time (through setting the currentTime or
calling pause() or finish()) but has no start time, it is paused.
* Otherwise, if it has no active timeline or no start time, it is idle.
By removing the mIsPaused flag the number of possible permutations of states is
reduced so the model is easier to reason about (see:
http://lists.w3.org/Archives/Public/public-fx/2014OctDec/0026.html).
This patch replaces the mIsPaused flag with checks for mStartTime.IsNull()
according to the rules outlined above.
The existing relationship between the particular versions of
AnimationPlayer::Play* (particularly in the CSSAnimationPlayer) subclass are
confusing because, for example, CSSAnimationPlayer::PlayFromStyle needs to be
careful to *not* call Play on CSSAnimationPlayer, but only on the parent
object (since otherwise we reset the sticky pause behavior).
This patch reworks this relationship by adding a protected DoPlay method that
performs the common pausing behavior. Play/PlayFromJS/PlayFromStyle then add
flushing, sticky pausing etc. as necessary.
This patch also removes the UpdateFlags enum and parameters previously used to
control whether we forced an update to style. This is no longer necessary since
we no longer call 'Play' from style. Instead we make Play always post restyles.
If we come across a case where we want to call Play and *not* post restyles, we
can re-add the flags then.
Roughly the same arrangement is true for Pause except that we don't currently
flush styles for CSS animations in PauseFromJS since it currently won't make any
observable difference.
This patch introduces an abstract method to AnimationPlayer to fetch the manager
object associated with the player. This method is implemented separate by
CSSAnimationPlayer and CSSTransitionPlayer to return the nsAnimationManager or
nsTransitionManager accordingly.
In order for AnimationPlayer objects to be able to notify their
collection/manager, the can either store an extra pointer member, or they can
navigate to the collection as follows:
player->source(animation)->target(element)->document
->presShell->presContext->manager->collection
This patch adds a getter for the first part of this journey up to the document.
Previously AnimationPlayer::Play() and AnimationPlayer::PlayState() would flush
styles as part of their operation. This, however, is only needed when the player
corresponds to a CSS Animation or CSS Transition. Now that we have concrete
subclasses for each of these cases we can move style flushing to the subclasses
and remove it from the base class (which is expected to be shared with
animations that are not dependent on style).
In order to be able to find the collection a player belongs to from its source
content, we first need to be able to determine which manager--the animation
manager or transition manager--to look up.
We eventually plan to push transition event dispatch down to a CSS
transitions-specific subclass of AnimationPlayer, so this seems like a suitable
point to introduce this class.
Using this subclass we can define a virtual GetManager method that will
return the appropriate animation/transition manager for the player.
This patch moves the code for queuing CSS animation events from
nsAnimationManager to CSSAnimationPlayer. In doing so, it also moves the
mLastNotification member and associated enum values.
AnimationPlayer::CanThrottle determines if an animation player has just finished
by inspecting the value of mLastNotification. This is problematic for two
reasons:
1. mLastNotification is intended to be used for events (as the XXX comment
notes)
2. mLastNotification is specific to CSS Animations and should be moved to
CSSAnimationPlayer.
To address this, this patch adds an extra member mIsPreviousStateFinished. The
Web Animations spec already defines animation players as having such a member:
http://w3c.github.io/web-animations/#previous-finished-state
We set it to true when we calculate the style for an animation that has
finished. This differs slightly from the code it is replacing as explained
below.
In the case of CSS Animations we perform the following sequence of steps on each
sample.
1. EnsureStyleRuleFor (calls CanThrottle, and maybe ComposeStyle)
2. GetEventsForCurrentTime
In the existing code, we update mLastNotification in (2) which happens on every
sample, even throttled samples.
In this patch, however, we update mIsPreviousStateFinished in (1) during the
ComposeStyle step which only happens for unthrottled samples. So, as of this
patch, in CanThrottle, we ask "have we newly entered the finished state since
the last *unthrottled* sample?", whereas previously we simply looked for
a change since the last sample, throttled or not. However, if the answer to the
question is "yes", then we'll run an unthrottled sample and update
mIsPreviousStateFinished so these should be functionally equivalent.
Another subtle difference is that this patch looks at the player's finished
state rather than the animation phase of its source content, and these will
produce different results in the case where the player is paused. However, since
paused animations are not run on the compositor, this should not matter.
In the case of CSS Transitions, AnimationPlayer::CanThrottle() is not currently
used and so mIsPreviousStateFinished is irrelevant.
Ultimately, both the existing and the new code is somewhat fragile but hopefully
this will be addressed by:
* Replacing mIsPreviousStateFinished with inspecting whether the finished
promise is settled (bug 1074630),
* Merging more of the code in nsAnimationManager and nsTransitionManager and
applying a unified approach to sampling that better accommodates these
considerations.
This patch takes the CSSAnimationPlayer object, currently defined in
dom/animation/AnimationPlayer.{cpp,h}, and moves it to
layout/style/nsAnimationManager.{cpp,h} where the rest of the CSS
Animations-specific code lives.
At the same time it extends the scope of the mozilla namespace block in
nsAnimationManager.h to also include the AnimationEventInfo and EventArray types
since these classes, which don't have an ns* prefix, probably should be in the
mozilla namespace anyway.
This patch extracts the logic for calculating animation styles from
AnimationPlayerCollection and puts the bulk of it into the Animation objects.
Some of the initial logic surrounding the animation player state (e.g. is it
paused or not, etc.) is put into AnimationPlayer.
In future we may shift this logic even further down to the AnimationEffect
objects but currently we don't create such objects unless necessary.
This patch moves code from AnimationPlayerCollection to AnimationPlayer.
However, there is one subtle change in logic involved. Previously, we would test
if the player had finished by getting the computed time of its source content
and checking if it was in the after phase or not. In this patch, however, we
simply check the play state to see if it is finished or not.
These two approaches differ in the case where an animation is paused after it
has finished. The animation phase approach will indicate the player has
finished, but the play state approach will indicate the player has paused (since
the "paused" state trumps the "finished" state). This, however, should not
produce any observable effect because when an animation is paused
mIsRunningOnCompositor will be false (we don't put paused animations on the
compositor).
This patch uses the PlayFromStyle/PauseFromStyle methods on CSSAnimationPlayer
to perform play/pause control. (This allows us to encapsulate mHoldTime and
mPaused. We will encapsulate mStartTime etc. in subsequent bugs.
The override behavior of play()/pause() with regard to animation-play-state is:
* pause()/play() override the current animation-play-state
* pause() causes the player to remain paused until play() is called regardless
of changes to animation-play-state
(* Calling play() will override the animation-play-state but won't "stick". i.e.
subsequently setting animation-play-state: paused will pause the animation.)
These different permutations are tested in the next patch in this series.
This interaction will probably become more complicated once we introduce
finishing behavior (since we might not want animations to restart when
setting animation-play-state: running).
For players running CSS animations and CSS transitions we should perform a style
flush before running play() so that we are operating on the most up-to-date
state of animation-play-state.
For transitions, which don't have a play-state property, we will still need to
run this style flush before running play() to get the right finishing behavior
if transition-duration has changed. We haven't implemented finishing yet (that's
bug 1074630) but I've kept the flush for both cases now since I'm afraid we'll
forget it later.
Also, since we don't have a subclass of AnimationPlayer for transitions yet I've
put the style flush in the base class. In future, when we add
CSSTransitionPlayer we can move the flush to only those players that need up to
date style information.
When an animation player is paused by script this overrides whatever
animation-play-state is set by style. The logic for producing the correct
override behavior will be added to nsAnimationManager but first we need
to record in the player where it was paused.
This patch introduces a CSSAnimationPlayer subclass of AnimationPlayer. This is
because when we have an animation player running a CSS animation it has some
special behavior not needed in the general case such as:
* Flushing style before performing certain operations to ensure we are using
the latest information.
* Dispatching CSS Animation events when we start/end.
* Storing extra state with regards to "how" the animation was paused.
This is because, for example, if an animation is paused by script this
overrides specified style.
This patch introduces the basic implementation of play() and pause().
There are a lot of gaps still because we don't yet:
* Support the pending state (to be covered in bug 927349)
* Support finishing behavior (to be covered in bug 1074630)
* Have a good way of updating animation state outside of style resolution (bug
1073336)
Also, we don't call these methods from CSS yet because the interaction between
play()/pause() and animation-play-state requires storing some extra state which
we introduce in subsequent patches in this series.
This patch introduces, temporarily, an update flag to indicate whether
play()/pause() operations need to post a restyle event. When these methods are
triggered by processing restyles we don't want to post another (unnecessary)
restyle event. In bug 1073336 we will remove the need for this.
We only need to store if an animation is paused or not, hence a bool is
sufficient. Furthermore, the convenience of using the same type as the specified
style of animation-play-state will disappear once pausing behavior is wrapped up
behind Play() and Pause() methods.
This patch makes Element::GetAnimationPlayers return not only current animations
but also animations that have finished but are filling forwards. This brings the
implementation into line with recent changes to the Web Animations spec and
allows querying all the animations that are currently affecting an element or
which are scheduled to do so in the future.
This patch adds a utility method to return if an animation is "in effect" or not
as defined by Web Animations:
http://w3c.github.io/web-animations/#in-effect
It also moves the utility method for querying if an animation is "current"
(IsCurrent) to the .cpp file since it is fairly long. (Bug 1046055 makes one of
the callers of IsCurrent inline-able which should offset any cost introduced by
this no longer being inline-able.)
It's not the player that's "current" (a Web Animations term for an animation
that hasn't yet finished), but its source content, if any. This patch renames
the method on AnimationPlayer accordingly.
At the same time this patch moves the method to the header file since it's
quite simple and could possibly benefit from inlining.
This patch takes the StickyTimeDuration defined in the previous patch and
uses it within the calculation of animation timing for parameters that are
expected to be +/- Forever.
This patch stores the animation name on the Animation object rather than its
AnimationPlayer. This is because Animation objects don't have a reference to
their AnimationPlayer but their AnimationEffect needs access to the animation
name.
This patch also adds an accessor for AnimationPlayer to get the name from its
Animation (since players *do* have a reference to their source animation
content).
The assertion in nsTimeStamp::operator >= occasionally fails due to a null RHS
timestamp when called from AnimationPlayer::GetCurrentTimeDuration, which, in
turn, is called from AnimationPlayer::SetSource.
The issue appears to be that we're not correctly initializing
AnimationPlayer.mPlayState. This value can be running (0) or paused (1) but we
only ever compare against the paused state (i.e. every other value is
effectively treated as running). If we don't initialize this we can end
up in the paused state but with mPauseStart not set to a valid (non-null)
TimeStamp. This creates an inconsistent state since we assume that when we're
paused mPauseStart is non-null, hence the assertion fails.
This gets tickled because, since bug 1040543, we call
AnimationPlayer::SetSource from nsAnimationManager::BuildAnimations *before* we
set mPlayState and mPauseStart.
This patch initializes mPlayState to the running state so we don't accidentally
end up in an inconsistent state.
It also removes some (now unnecessary) initialization of mPlayState and
mPauseStart from nsTransitionManager::ConsiderStartingTransition.
In future we could also consider reworking nsAnimationManager::BuildAnimations
so that we call SetSource on the new animation player *after* setting up its
play state. That may be more correct and would further avoid this problem but
may not be necessary since all that code is likely to change in the near future.
This patch changes the inheritance of ElementPropertyTransition so that it is
a subclass of Animation not AnimationPlayer.
The only thing special about ElementPropertyTransition is it stores some extra
state for reversing transitions and an extra ValuePortionFor convenience method.
This reversing behavior is implemented by the transition manager by creating
a new AnimationPlayer (i.e. it is *not* a property of the AnimationPlayer). As
a result this extra state can be pushed down to Animation which simplifies the
code significantly.
In future if we implement KeyframeEffect as a separate object we may be able to
push transition-specific state down to KeyframeEffect instead.
In this fourth step of dividing functionality between AnimationPlayer and
Animation, we move the mIsLastNotification and related methods/enums from
AnimationPlayer to Animation.
It is somewhat unclear where this belongs. This member is used to determine
which event to send for CSS Animations. The thinking behind moving this to
Animation is that if an animation that has already dispatched its animationstart
event was transferred to a new animation player with a similar current time then
I think it is expected that such an animation would *not* dispatch another
animationstart event. That suggests that event-state is a property of the
Animation not the AnimationPlayer.
Obviously, this needs to be defined somewhere (namely, the CSS Animations <->
Web Animations integration spec likely to become "CSS Animations Level 4"). Once
that behavior is agreed upon, if AnimationPlayer proves to be the more suitable
home for this member then it should be relatively straightforward to move the
member back at that time.
As the third step in dividing functionality between AnimationPlayer and
Animation this patch moves the mIsFinishedTransition member and related methods
from AnimationPlayer to Animation.
At the same time we rename SetFinishedTransition to SetIsFinishedTransition.
As the second step in dividing functionality between AnimationPlayer and
Animation, this patch moves the AnimationTiming member from AnimationPlayer to
Animation.
Most of this patch is simply moving code around. However, one significant
functional difference is that Animation::GetLocalTime() uses the mParentTime
member which is set when the Animation is updated by the player it is attached
to.
Other less significant differences are:
* AnimationPlayer::GetLocalTime is renamed to GetCurrentTimeDuration
In Web Animations, animation players have a (writeable) "current time" and
animations have a (read-only) "local time".
We would call the method simply "GetCurrentTime" (instead of
"GetCurrentTimeDuration") but GetCurrentTime is the name of the method used in
the content-facing API where it returns a double.
* "IsCurrent" is defined on both AnimationPlayer and Animation with the version
in AnimationPlayer serving mostly as a convenience shortcut to the version on
Animation.
* Animation::GetComputedTiming (previously on AnimationPlayer) now makes the
timing parameter optional since most of the time it is not needed.
As the first step in dividing the functionality currently contained in
AnimationPlayer between AnimationPlayer and Animation this patch moves the set
of keyframe properties to the Animation.
These properties are returned from the Animation by a couple of Properties()
methods that provide direct access to the member variable. In future it is
anticipated that the non-const version will be replaced with an appropriate
setter function. This will likely happen when we implement a separate
KeyframeEffect object as defined by the Web Animations API.
With regards to error checking, nsAnimationManager checks the result of
AnimationPlayer::GetSource() and handles the case where it is nullptr.
nsTransitionManager, however, simply asserts that GetSource() is never null much
like it also asserts that there is only one property with one segment in the
animation. Eventually this code should be made more generic which will probably
happen in bug 999927.
This patch makes AnimationPlayers pass their current time down to the Animation
they are playing.
Since all Animations need from their players is their time, this avoids adding
a pointer back to their AnimationPlayer.
This patch renames mozilla::ElementAnimations to mozilla::dom::AnimationPlayer
and moves the code from layout/style/AnimationCommon.cpp to
dom/animation/AnimationPlayer.cpp.
It also moves various helper classes needed by AnimationPlayer to
AnimationPlayer.cpp and moves them from the mozilla::css namespace to the
mozilla namespace.
Beyond that, there are no functional changes contained in this patch.
The renaming of various members and variables that used to refer to
ElementAnimation objects but now refer to AnimationPlayer objects--to give them
a more appropriate name--is performed in a subsequent patch.
--HG--
rename : layout/style/AnimationCommon.cpp => dom/animation/AnimationPlayer.cpp
rename : layout/style/AnimationCommon.h => dom/animation/AnimationPlayer.h
A document that belongs to an iframe that is display:none as no associated pres
context from which to get a refresh driver. However, in this case
document.timeline.currentTime should still never go backwards (since document
timelines are supposed to be monotonically increasing).
This patch makes AnimationTimeline record the last value returned for the
current time so that if the document becomes display:none we can still return
the most recently used time.
This patch changes the order in which we look for matches when updating existing
animations. Previously we would iterate through new animations in a forwards
direction but match old animations by going through the list of animations
backwards.
This patch makes us iterate through both lists in a backwards direction. That
means that if we have:
animation: anim 100s
and later we make it
animation: anim 100s, anim 100s
Then the new animation will be added to the *start* of the list, i.e. prepended,
and the resulting animation will not restart.
Previously when updating animations we'd generate a new list of animation
objects then try to match up animations from the existing list and copy across
state such as start times and notification flags. However, this means that from
the API we end up returning different objects.
This patch makes us maintain the same object identity when updating an existing
animation. It does this by looking for matching animations in both lists. If it
finds a match it copies the necessary information from the *new* animation to
the *existing* animation (but preserving the start time, last notification
etc.). Then, finally, it puts the *existing* animation in the list of *new*
animations and removes the corresponding *new* animation. The existing
animation is also removed from the list of existing animations so that it only
matches once.
The method used for matching is probably not intuitive but this is addressed in
a subsequent patch in this series.
This patch simply factors out the conversion from a TimeStamp value to
a nullable-double value relative to the start of the timeline. This is so that,
in a subsequent patch, this functionality can be reused by ElementAnimation
when it reports its start time (which is currently recorded as a TimeStamp).
AnimationTimeline::GetCurrentTime returns the time value of the timeline as
a double. For internal calculations however it is more useful to get this as
a mozilla::TimeStamp.
This patch splits the calculation of the current time into two stages:
calculation as a timestamp then conversion to a double.
Nicholas Nethercote
Brian Birtles
Jonathan Watt
Mason Chang
Daniel Holbert
David Zbarsky
Peter Van der Beken
Ehsan Akhgari
Alexandre Poirot
Jonathan Griffin
Mike Hommey
Benoit Jacob