This is not strictly necessary yet but we will want to implement methods
like GetAnimations() on the base class, AnimationTimeline, so we may as well do
that now rather than adding that code to DocumentTimeline and moving it later.
This patch re-uses Animation::mSequenceNum to store the index of CSS animations
within their corresponding animation-name property. When the animation is
removed from an animation-name property it reverts to using the default
animation composite order.
This patch also updates Animation::DoCancel to call UpdateTiming instead of
UpdateEffect. This is because UpdateTiming is responsible for updating the
sequence number (when custom composite order is not in effect). When we remove
an animation from animation-name it will be cancelled and at that point we
expect its sequence number to be cleared which will only happen if
UpdateTiming gets called.
Add a virtual method we can use to determine when an animation is having its
sequence number set by some other mechanism than the general logic
defined for animations.
This allows CSS animations and transitions to re-use the sequence number for
their own purposes. Typically what will happen is something like this:
1. A CSSAnimation is created corresponding to an item in the animation-name
property.
At this point CSSAnimation::IsUsingCustomCompositeOrder() will return true
and nsAnimationManager will set the sequence number based on the position of
the animation in animation-name.
2. If at a later point the animation is removed from the animation-name but kept
alive by script, CSSAnimation::CancelFromStyle will be called which will
clear the custom sequence number (i.e. set it to kUnsequenced) and also
update the CSSAnimation's state such as
CSSAnimation::IsUsingCustomCompositeOrder() returns false.
3. Then, then the CSSAnimation next transitions out of the idle state it will
have its sequence number set just like any other Animation and be ordered
like any other Animation (since we can no longer use animation-name to
determine its composite order).
This behavior is added in subsequent patches in this series (and likewise for
CSS transitions too).
This patch introduces a method that will be used for sorting animations based on
their composite order. The method is based on the API for Comparator objects (as
used by nsTArray and co.) which have a LessThan method. (For the
Comparator::Equals method we can used pointer equality since no two independent
objects should have equal composite order.)
Web Animations defines Animations as having a globally unique sequence number
for the purpose of prioritization:
http://w3c.github.io/web-animations/#animation-sequence-number
As of the writing of this patch, the spec says the sequence number is updated
when the Animation is created. This is problematic and I have proposed that
actually this should be updated from each transition from idle:
https://lists.w3.org/Archives/Public/public-fx/2015AprJun/0054.html
This doesn't seem to have met any opposition so I will update the spec to
reflect this soon.
This patch implements the behavior of updating the sequence number on each
transition from idle.
To make sure we perform this on each change to timing this patch removes
a couple of instances of early returns to ensure that UpdateTiming is called.
The current maximum sequence number is simply a class static and we make no
attempt to deal with wraparound. This is because we only update this number when
an animation transitions from idle which only happens when an animation is
created or script calls cancel() followed by play() on the animation. Supposing
that across all content this happenned an unlikely 1 billion times a second we
still wouldn't exhaust the range of the unsigned 64-bit int for about 585 years.
We'd like to make kUnsequenced be zero and make the static represent the
current maximum. This would probably be easier to understand and recognize in
a debugger. However, later in this patch series we will make CSS animations and
CSS transitions override this sequencing behavior. If we define kUnsequenced
to be zero and they accidentally assign zero as an actual sequence number then
they'll run into trouble. To avoid that we set kUnsequenced to UINT64_MAX.
Prior to this patch we cancel animations in AnimationCollection::Destroy but
this is not called automatically when the property holding the collection is
destroyed via its destructor. When an element is unbound from the tree we
destroy its animation properties but don't call AnimationCollection::Destroy.
This means, that in such circumstances:
* We won't create animation mutation records for the removed animations
* Once we start registering animations with a timeline they won't have a
chance to remove themselves from the timeline (meaning
document.timeline.getAnimations()) will keep returning them
* Once we go to implement the animationcancel and transitioncancel events we
won't fire them in this case (assuming we implement the queueing/dispatch of
those events as part of the cancel code)
This patch addresses this by moving the call to cancel each animations to the
property destructor for the animation properties.
We do this first so we can land this change separately to ease bisecting any
regressions it might trigger.
We have already resolved to make calling Finish() clear the pause state (see
https://lists.w3.org/Archives/Public/public-fx/2015AprJun/0038.html, item 2).
Doing that involves resolving the start time when the animation is paused.
Furthermore, as a separate change, we resolved to make the finished promise not
resolve when the animation is paused. That suggests making UpdateFinishedState()
only resolve the finished promise when PlayState() == Finished rather than using
IsFinished() which returns true even if the animation is paused.
However, if we compare PlayState() == Finished in UpdateFinishedState() then we
will *not* resolve the finished promise when the animation is play-pending since
PlayState() == Pending in that case (pause-pending is ok since the call to
SetCurrentTime will cause a transition to the Paused state). Furthermore, the
existing call to cancel the pending play task will effectively leave this
animation forever pending. Hence, in this patch we unconditionally fill in the
start time.
The point of making pausing async is to allow time to sync up the current time
with the compositor. Setting the current time manually should simply force it to
the specified time and complete the pause action, not abort it. (We do a similar
thing for a pending play. For a pending play we're waiting to establish
a suitable start time. Manually setting the start time in that case simply
forces the start time to the specified time and completes the play operation.)
Animation::ResumeAt contains an assertion that, when we exit the play-pending
state, checks we either have a resolved start time or a resolved hold time.
That's normally true but if we are aborting a pause on animation that is
finished we can end up with a resolved start time (since we don't clear the
start time when we're aborting a pause) and a resolved hold time (either
because the regular finishing behavior set one, or, because play() applied
auto-rewinding behavior and set it).
In that case we should actually respect the hold time and update the start time
when resuming the animation. However, ResumeAt won't update the start time if it
is already set.
This patch fixes that by clearing the start time in DoPlay in the case where we
are aborting a pause and have a hold time.
This patch makes Cancel() call PostUpdate which clobbers certain state in style
so that animated style is correctly flushed when an animation is cancelled.
The main difficulty with this is that we *don't* want to call this when we're
cancelling an animation as a result of a style update or else we'll trigger
needless work. The pattern elsewhere has been to define a *FromStyle() method
for this case (e.g. CSSAnimation::PlayFromStyle, PauseFromStyle). This isn't
ideal because there's always the danger we will forget to call the appropriate
*FromStyle method. It is, however, consistent. Hopefully in bug 1151731 we'll
find a better way of expressing this.
This patch is a fairly minimal rename of the AnimationPlayer interface. It
leaves a bunch of local variables and helper classes still using the word
"player". These will be addressed in subsequent patches that don't require DOM
peer review.
We define KeyframeEffectReadonly in KeyframeEffect.cpp since Web Animations also
defines KeyframeEffect and when we come to implement that I expect we'll define
it in the same class, maybe even using the same object.
This patch also adds a few missing includes in places where
KeyframeEffectReadonly is used so that we're not just cargo-culting it in.
Most of this is fairly obvious. However, the addition of 'override' to
ElementPropertyTransition::Name() is not strictly necessary. It was simply added
because while making these changes I accidentally dropped the 'virtual' keyword
from the method in the superclass and the compiler didn't complain. Adding this
will hopefully make it harder to create the same bug in the future.
This patch (after stepping through the call graph) affects the following
places:
* CommonAnimationManager::GetAnimationsForCompositor, which is used
only by nsDisplayListBuilder::AddAnimationsAndTransitionsToLayer,
which already checks the individual animations (so really no change)
* AnimationPlayerCollection::CanThrottleAnimation
* ActiveLayerTracker::IsStyleAnimated
* nsLayoutUtils::HasAnimationsForCompositor
* nsLayoutUtils::HasAnimations (which is used only to check whether we
can make the 0-opacity optimization)
I believe it makes sense to change all of these locations (although in
the long term we want to throttle (or similar) more animations).
Without this patch, I believe we're forcing the creation of an opacity
layer because we think we have animations to send to it.
This patch adds a method for testing if an animation is "in play" which is
a term defined in the Web Animations spec. This is in preparation for removing
some slightly redundant code in IsRunning and aligning better with the spec.
In preparation for introducing IsInPlay (where "in play" is a term in the Web
Animations spec), this patch aligns the existing IsCurrent with the definition
in the spec that says an animation effect is only current if it is attached
to an animation (player in our current naming) that is not finished. In order
to ensure that we need to pass the animation/player into the method.
This actually changes the behavior of IsCurrent since now we will return false
for animations that are finished. As far as I can tell, all the call sites that
are requesting current animations should only be concerned with animations that
are actually running. If not, they need to be adjusted to look for animations
that are either current or in effect.
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 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.)
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.
