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.
This depends on bug 1086937 patch 1 because it requires that
ResolveStyleWithReplacement support eRestyle_ChangeAnimationPhase on
::before and ::after pseudo-elements.
It also depends on patch 1 of this bug for the reasons described in
patch 1's commit message.
This is needed for bug 960465 so that we can use these hints to detect
whether pending restyles include restyles other than those for
animations. In other words, patches for bug 960465 (or perhaps a
dependent bug that lands before it) will require that all animation
restyles use an animation-specific nsRestyleHint.
It is also, on its own, a performance improvement for animations and
transitions, since we will stop rerunning selector matching on the
animating element during the progress of the animations or transitions.
Once we remove eRestyle_ChangeAnimationPhase the performance improvement
will even become slightly better.
Note that the eRestyle_ChangeAnimationPhase is needed in some cases
because we use PostRestyleForAnimation in the non-animation-restyle
phase when we have a style rule that we need to add during the animation
restyle phase. (It's not needed during the progress of the animation,
though. But hopefully both eRestyle_ChangeAnimationPhase will go away
soon, after bug 960465. And hopefully the way we tick animations will
also change to look more like the animation-only restyle, but without
the main-thread-suppressed (throttled) animations.)
I confirmed that this assertion fires (along with the other failures)
when running layout/style/test/test_transitions_events.html with patch 3
but not patch 1.
Without this patch, patch 3 will cause bugs where we'll never remove the
cover rule we create during the process of starting a transition. This
won't actually be problematic during the transition, since the
transition will overwrite it, but once the transition completes, the
cover rule will still be around, and we'll be stuck with the
pre-transition value instead of the post-transition value.
It's possible it also fixes existing bugs prior to the patch series in
this bug.
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.
We often set mStyleRuleRefreshTime to null to ensure styles get updated.
However, CanThrottleTransformChanges doesn't check for this case and blindly
does subtraction using this value.
Until now we've got away with this but now that we set mStyleRuleRefreshTime to
null when making changes via the API this case crops up in different
circumstances and we can trip over it.
This patch simply adds a null check before using mStyleRuleRefreshTime in
CanThrottleTransformChanges. All other cases where we operate on
mStyleRuleRefreshTime check for null.
nsAnimationManager provides GetAnimationPlayers while nsTransitionManager
provides GetElementTransitions. Both perform the same function, namely, fetching
(and optionally creating if it does not exist) the AnimationPlayerCollection for
the specified element/pseudo. Furthermore, both take the same arguments.
This patch aligns the method names and makes this a virtual method on the base
class CommonAnimationManager so that it can be used generically from a pointer
to a CommonAnimationManager.
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.
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).
