Now that DocumentTimeline observes the refresh driver we can use regular
ticks to remove unnecessary animations.
We do this because in a subsequent patch, in order to provide deterministic
enumeration order when ticking animations, we will store animations in an array.
Removing an arbitrary element from an nsTArray is O(n) since we have to search
for the array index first, or O(log n) if we keep the array sorted. If we
destroy a subtree containing n animations, the operation effectively becomes
O(n^2), or, if we keep the array sorted, O(n log n). By destroying during a
tick when we are already iterating over the array, however, we will be able
to do this much more efficiently.
Whether an animation is newly associated with a timeline, or is disassociated
from a timeline, or if it merely has its timing updated, the behavior
implemented in this patch is to simply make sure we are observing the refresh
driver and deal with the animation on the next tick.
It might seem that we could be a lot more clever about this and, for example, if
an animation reports NeedsTicks() == false, not start observing the refresh
driver. There are various edge cases however that need to be taken into account.
For example, if a CSS animation is finished (IsRelevant() == false so that
animation will have been removed from the timeline), and paused
(NeedsTicks() == false), and we seek it back to the point where it is relevant
again, we actually need to observe the refresh driver so that it can dispatch an
animationstart event on the next tick. A test case in a subsequent patch tests
this specific situation.
We could possibly add logic to detect if we need to fire events on the next tick
but the complexity does not seem warranted given that even if we unnecessarily
start observing the refresh driver, we will stop watching it on the next tick.
This patch removes some rather lengthy comments from
AnimationTiming::UpdateTiming. This is, in part, because of the behavior
described above that makes these comments no longer relevant. Other parts are
removed because the Web Animations specification has been updated such that a
timeline becoming inactive now pauses the animation[1] so that the issue
regarding detecting timelines becoming active/inactive no longer applies
since animations attached to an inactive timeline remain "relevant".
[1] https://w3c.github.io/web-animations/#responding-to-a-newly-inactive-timeline
This patch adds a utility method to Animation which takes a time in the
same time space as "current time", i.e. "animation time" and convert it to
a TimeStamp. Subsequent patches in this series will use this method to
take the time when an event was scheduled to occur and convert it to a
TimeStamp so it can be compared with other event times. This allows us to
dispatch events in the order they would have fired given an infinitely
frequent sample rate.
--HG--
extra : rebase_source : 0b4f98b932bb2751bac24b4383fe20613176f0c4
The Web Animations specification has replaced the term "sequence number" with
references to a global animation list. This patch applies similar naming
to our animation structures.
We currently determine if we need refresh driver ticks when composing style
but sometimes we might not need ticks for composing style but we might need
one more tick in order to queue a final end event. Currently, this doesn't
seem to be a problem because FlushAnimations calls Animation::Tick where we
queue up events. When we remove the call to Animation::Tick from
FlushAnimations in order to make FlushAnimations purely responsible for
posting restyles, however, we will create a situation where we might mark an
animation collection as no longer needing refreshes and not simultaneously
queueing the corresponding event. If another animation collection is deleted in
the meantime we may trigger the code that causes us to disassociate from the
refresh driver and the corresponding event will never be dispatched.
Long-term (bug 1195180) we will check if it we can stop observing the refresh
driver and queue events in the same step. Until then, this patch adds a method
to detect this particular situation and uses it to avoid unregistering from
the refresh driver while we still have end events to queue.
Now KeyframeEffect.SetTiming() updates the owning animation timing and relavance, so
we don't need to call each methods respectively for the animation any more.
We currently have a series of methods that clobber various bits of animation
state to force animations on layers to be updated. This aligns closely with
the restyle code introduced in this patch series.
By re-using RequestRestyle when updating animations on layers, not only should
we be able to simplify the code somewhat but, in future, we should also be able
to have Animation objects use the same mechanism to update layers during
a regular tick.
For example, currently we have a bug where when an animation starts after
a delay with the same value as the backwards fill then we don't send the
animation to the compositor right away (see
https://dxr.mozilla.org/mozilla-central/rev/d6ea652c579992daa9041cc9718bb7c6abefbc91/layout/style/test/test_animations_omta.html#287).
By adding this Restyle::Layer value we should be able to fix that in future.
In preparation for ultimately being able to run animations without a manager,
this patch moves the request restyle code from FlushAnimations to
Animation::Tick. (Ultimately most of this functionality should move to the
KeyframeEffect but for now Animation is fine.)
We want to move the newly-introduced RequestRestyle call from FlushAnimations
to Animation::Tick. However, nsAnimationManager::CheckAnimationRule calls
Animation::Tick so this would cause us to start posting animation restyles
within a restyle.
Typically, Animations have an effect (currently there is only one type of
effect: KeyframeEffectReadOnly) and when there is any change in timing they
pass it down to their effect. However, the Animation is dependent on the
duration of the effect for determining if it is "finished" or not. As a result,
when an effect's timing changes, the owning Animation needs to know.
(The way this *should* work is that effects should tell their animation or
trigger some chain of events that causes animation's to update themselves.
However, the current implementation of effects is fairly primitive and does
not do this or even have a reference to the owning Animation. When we
implement the script API for updating the timing properties of effects we will
have to fix this but for now it is up to code in layout/style to update the
Animation when it touches the corresponding effect's timing.)
nsAnimationManager::CheckAnimationRule currently does this by calling
Animation::Tick() which ensures the Animation's finished state is updated
accordingly.
Ultimately we want to ensure that Animation::Tick is called exactly once per
frame (and at the appropriate point in that frame) so we'd like to remove this
call from CheckAnimationRule.
This patch achieves that by:
* Making Animation::SetEffect update the animation's timing - this is necessary
for animations that are created by CheckAnimationRule and will be
necessary when once we make Animation.effect writeable from script anyway.
* Calling Animation::SetEffect even for the case when we are updating the
existing effect.
Another side-effect of calling Animation::Tick within
nsAnimationManager::CheckAnimationRule is that CSSAnimation::Tick queues
events. There are some tests (e.g. layout/style/test/test_animations.html) that
assume that animationstart events are dispatched immediately when new
animations are created. That will change with bug 1134163 but for now we
should maintain this existing behavior since changing this might introduce
compatibility issues that are best dealt with as a separate bug rather than
blocking this refactoring. To that end, this patch also explicitly queues
animationstart events for newly-created animations.
Animation::ComposeStyle uses IsFinishedTransition to skip doing work for
transitions that have run their course. We can, however, generalize this to
cover all animations that are not currently contributing to the animated
style--that is animations that are not "in effect".
We need to add this check *after* we update aNeedsRefreshes since an animation
that is not "in effect" because it has a delay and no backwards fill (in this
case it will have a play state of "running") still needs refreshes.
Previously we used IsFinishedTransition so that if the only animations present
are finished transitions we could throttle the tick. In fact, this probably
shouldn't even be necessary since we shouldn't be calling CanThrottle if
AnimationCollection::mNeedsRefreshes is false. However, so long as we're
performing this test it turns out we can generalize this further and throttle
ticks for all finished animations that are not newly finished, regardless of
whether they are running on the compositor or not (although this method won't
be called unless the animation property could be run on the compositor anyway).
This method is somewhat confusing. For one, it is not strictly limited to
animations that are running on the compositor. It appears to only return true
when the animation is running on the compositor but the mIsRunningOnCompositor
flag doesn't get cleared when the animation finishes (bug 1151694). As a result
this method also deals with animations that are now running on the main thread.
This patch makes us deal with such animations more consistently.
This patch also reworks this method so that it's hopefully a little easier to
follow and a little more consistent since I spent several hours trying to
understand the different combinations of inputs this method could take and what
question it was trying to answer.
The long-term plan is to drop the mozilla::css namespace altogether. Before we
go to much further with refactoring code in AnimationCommon, we should drop
usage of the mozilla::css namespace. Specifically, this patch moves the
CommonAnimationManager and AnimValuesStyleRule classes to the mozilla namespace.
The long-term plan is to drop the mozilla::css namespace altogether. Before we
go to much further with refactoring code in AnimationCommon, we should drop
usage of the mozilla::css namespace. Specifically, this patch moves the
CommonAnimationManager and AnimValuesStyleRule classes to the mozilla namespace.
We'll likely address this as part of bug 1151731 when we sample animations from
their timeline.
--HG--
extra : commitid : 9g00bBtDIue
extra : rebase_source : 12d9de2524eb3133bef5a5bcf4c84d4759ccbbca
We only store relevant animations on the timeline. Relevant animations are
any animations that are running or yet to run ("current animations") or
which have finished but are still applying a fill mode ("in effect animations").
AnimationTimeline.getAnimations() only ever returns relevant animations so
this is the minimum set we need to keep track of. Keeping track of any more
than this would prevent us from garbage-collecting any no longer relevant
animations since we keep a strong reference to this animations.
The reason we keep a strong reference is that if an animation is attached to
a timeline, even if there are no references to it from script or markup it
needs to be kept alive in order to dispatch events or resolve promises. An
irrelevant animation however is not going to do either of these things without
outside intervention so we don't need to keep it alive.
--HG--
extra : commitid : WLEUccOqAk
extra : rebase_source : 5c3c987d6c95ca7072c6178349dc113d2f1e5053
The connection between an Animation and an AnimationTimeline is optional. That
is, it is possible to have an Animation without an AnimationTimeline. Until now
we have often just assumed the timeline will be set but eventually we need to
support the possibility of the timeline being null. Indeed, later in this patch
series we will set the timeline out-of-band (i.e. not in the constructor) using
SetTimeline which opens up the possibility that timeline will be null for
a period of time.
This patch paves the way for having an optional timeline by storing the global
used for, e.g. creating promises, on the Animation object itself.
--HG--
extra : commitid : Ew9Zp4t36lV
extra : rebase_source : 16c9de9525a3562ff10e41fdf1602384a4e366e3
This is needed not only for supporting other kinds of timelines, but also for
when we come to implement SetTimeline(AnimationTimeline* aTimeline).
--HG--
extra : commitid : B836jCSbgNL
extra : rebase_source : 2592e66b2a9009f85ec0189ebecf5dba3c9bf8e0
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.
--HG--
extra : commitid : 7GU6Dr9lnPO
extra : rebase_source : d5e788874c72c422b57efbdb81404c79df6d505b
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.
--HG--
extra : commitid : 2KrTezItH3q
extra : rebase_source : 50de87465deef85558ca50de5e6286f7b5603051
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).
--HG--
extra : commitid : B8nPFXzQMfF
extra : rebase_source : 42439fb1dd32a789e270dc0c51af2c660f4593eb
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.)
--HG--
extra : commitid : 88oD4UFx5to
extra : rebase_source : 1b30272451c189161a08efac3da48d72e10d8e52
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.
--HG--
extra : commitid : DMw8uKjg4Hz
extra : rebase_source : 9e98b3346f0297efce3ecfa0b2dd8a9c13075dca
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.
--HG--
extra : commitid : KzukSO91RMH
extra : rebase_source : 54ed2aeb69d8bceca424c70c7f33d4bf92d54546
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.
--HG--
extra : rebase_source : 499ad0530eac0ee62c8ed2df41360c45abc34816
This is much easier to read at call sites and prevents accidentally using the
default value when another value might be more suitable.
--HG--
extra : rebase_source : b1c05d8bf7b97744e53f2ecc676561f3a4a80888
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.)
--HG--
extra : rebase_source : 614ed9ef01204e4137783c0d48e975eb8febbe2a
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.
--HG--
extra : rebase_source : 83f980d6cbc34375274f30f6527992b4fec7f639
Brian Birtles
Hiroyuki Ikezoe
Carsten "Tomcat" Book
Andrew McCreight