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.
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).
In order to add AnimationPlayerCollection::NotifyPlayerUpdated, collections
need a way of updating their managers to inform them that their mNeedsRefreshes
flag has changed and hence the manager may need to resume observing the refresh
driver.
Currently, only nsAnimationManager makes use of mNeedsRefreshes and provides
a CheckNeedsRefresh method. In order to allow AnimationPlayerCollection to
operate independently of the type of manager it is attached to (and because
there's a lot of similar code here that we eventually want to move to a common
manager anyway), this patch moves CheckNeedsRefreshes and associated
machinery to CommonAnimationManager.
I originally wrote this to see if it would fix bug 1086937, but it
didn't.
Note that this conflicts a bit with the patch in bug 1085769; whoever
lands second will have some merging (though it shouldn't be difficult).
The updating of the style rule is needed as part of the animation-only
style update, but it shouldn't be in the general restyling code, so it
has moved there.
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.
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 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).
This patch changes ElementAnimation::GetLocalTimeAt so that instead of taking
the current time as input, it uses the animation's mTimeline member to look up
the current time of the associated timeline. As a result of this, it is possible
to remove a few instances of querying the refresh driver for the current time.
Further instances are removed in subsequent patches.
Furthermore, in order to keep the use of time sources consistent, the mStartTime
of new transitions and animations is initialized with the current time from the
animation's timeline rather than with the latest refresh driver tick.
Since this time could, in future, be null, GetLocalTime(At) is updated to check
for a null start time.
GetLocalTimeAt is also renamed to GetLocalTime in the process.
When we expose ElementAnimation objects to script they need to have a parent
object so they can be associated with a Window.
This patch adds a pointer from an ElementAnimation to its AnimationTimeline.
This patch removes ElementAnimations and replaces all references to
ElementAnimations with references to CommonElementAnimationData.
We don't bother to rename variables like 'ea' or methods like
GetElementAnimations to correspond with the data type
(CommonElementAnimationData) since CommonElementAnimationData will soon be
renamed in bug 1010067 and we'll rename these things then.
The ElementAnimationsPropertyDtor function is renamed and merged in a subsequent
patch in this series.
In order to unify ElementAnimations with CommonElementAnimationData we need to
find another home for GetEventsAt which is specific to queueing CSS Animation
events. For now nsAnimationManager seems an appropriate place and corresponds
more closely to the arrangement for transitions (where nsTransitionManager is
responsible for queueing the events by iterating over the list of animations).
In future we may reintroduce a subclass of animation specific to CSS Animations
that does this event queueing but for now nsAnimationManager seems to be a
suitable place.
This patch simply moves the code and replaces references to "mAnimation" with
"eEA->mAnimation". There are no functional changes.
This patch moves PostRestyleForAnimation from ElementAnimations to the base
class CommonElementAnimationData and makes use of it within nsTransitionManager.
IsForElement and PseudoElement are currently only defined on ElementAnimations
but could be used for transitions. This patch moves these methods to the common
base class CommonElementAnimationData and also makes use of PseudoElement within
nsTransitionManager.
This patch moves PostRestyleForAnimation from ElementAnimations to the base
class CommonElementAnimationData and makes use of it within nsTransitionManager.
IsForElement and PseudoElement are currently only defined on ElementAnimations
but could be used for transitions. This patch moves these methods to the common
base class CommonElementAnimationData and also makes use of PseudoElement within
nsTransitionManager.
This patch still leaves ElementAnimations|
ElementTransitions::GetAnimationsForCompositor as shortcuts
for the method now defined on CommonElementAnimationData.
This patch moves HasAnimationOfProperty to CommonElementAnimationData. It also
takes the chance to start removing some redundancy from nsLayoutUtils
/ ActiveLayerTracker. Some of this should never have been added in the first
place and some could have been removed earlier on but while we're fixing up
HasAnimationOfProperty it seems like an appropriate time to fix up its call
sites too.
Also, since HasAnimationOrTransition actually returns an object, not a bool, we
this patch renames it to GetAnimationsOrTransitions.
In a number of places in nsAnimationManager we have the following sequence of
calls:
CommonElementAnimationData::EnsureStyleRuleFor
ElementAnimations::GetEventsAt
nsAnimationManager::CheckNeedsRefresh
nsAnimationManager::EnsureStyleRuleFor already does exactly that so we should
just reuse it.
At the same time we rename EnsureStyleRuleFor to UpdateStyleAndEvents since
that's a bit more accurate. It's also confusing to have two methods of the same
name (but on different objects) that don't exactly correspond in terms of
the scope of what they do.
Both ElementAnimations and ElementTransitions have an EnsureStyleRuleFor method.
The ElementAnimations version is a more general of the ElementTransitions one
with the exception that the ElementTransitions version checks for finished
transitions. This patch moves the code from ElementAnimations to
CommonElementAnimationData with one minor change: adding the checks for finished
transitions. The ElementTransitions version is removed.
Since the ElementAnimations version contains a second parameter, aIsThrottled,
callers of ElementTransitions must include this extra parameter. In
a subsequent patch we add an enum for this parameter to make call sites easier
to read.
The ElementAnimations version also sets the mNeedsRefreshes member so at the
same time we move mNeedsRefreshes to CommonElementAnimationData. Furthermore,
since the ElementAnimations version which we have adopted returns early if
mNeedsRefreshes is false, this patch ensures that when we call
EnsureStyleRuleFor from ElementTransitions::WalkTransitionRule, we set
mNeedsRefreshes to true first.
Another difference to account for is that the ElementTransitions version of
EnsureStyleRuleFor *always* sets mStyleRule (even if it doesn't add anything to
it) where as the ElementAnimations version only creates the rule when necessary
so we need to add a check to ElementTransitions::WalkTransitionRule that
mStyleRule is actually set before using it.
This patch simply moves the code from ElementAnimations to ElementAnimation so
that it can later be used in transitions code and so we can later move
EnsureStyleRuleFor to ElementAnimation.
This patch simply shifts the event-related code from GetPositionInIteration to
GetEventsAt. Although there are simplifications that could be done to
GetEventsAt, they are deferred to a subsequent patch so as not to obscure the
translation of code from one function to another.
As a result of moving event-related handling from GetPositionInIteration it no
longer needs to support different main-thread vs compositor modes.
This patch makes ElementAnimations::GetPositionInIteration return
a ComputedTiming object instead of just a time portion (time fraction).
Since the ComputedTiming object includes phase information, we can fix those
parts of EnsureStyleRule and GetEventsAt that were temporarily using the time
portion to guess if the animation might have finished or not.
This patch moves event queuing out of EnsureStyleRuleFor into a separate method.
This is a preparatory step towards making GetPositionInIteration into a more
generic method for calculating the current time fraction.
In order to achieve this, GetPositionInIteration needs to be able to calculate
the correct time portion for times outside the range [0, 1] even when it is not
passed a ElementAnimation object. Specifically, it needs the fill mode of the
animation to be passed in.
(Rather than using FillForwards/FillBackwards this patch just compares the
NS_STYLE_ANIMATION_FILL_MODE_* values directly but FillForwards/FillBackwards
are restored in a subsequent patch when they are added to the struct used to
lump the timing parameters together.)
There are a number of places where positionInIteration is used to determine if
the current sample occurs in the active phase or after. This is sub-optimal but
is fixed in a subsequent patch in this series.
The actual work of removing event queuing from GetPositionInIteration is
deferred to a subsequent patch in order to keep the changes as small as
possible. This patch simply makes separate calls to GetPositionInIteration for
interpolating and for event queuing.
As a result, transitions are now stored using a pointer to the base class,
mozilla::ElementAnimation. We downcast to a transition only when necessary. No
error-checking of the result of AsTransition is performed since we only ever
call it on the mAnimations member of ElementTransitions.
We currently have mozilla::StyleAnimation as well as nsStyleAnimation. This
patch renames StyleAnimation back to ElementAnimation.
Although ElementAnimation is very similar to ElementAnimations, in the near
future we expect to retire ElementAnimations and replace it with a common
AnimationSet-like structure that is covers the features of ElementAnimations and
ElementTransitions.
This patch takes StyleAnimation and makes it ref-counted heap object. This
should allow us to store StyleAnimation and its subclasses (transitions only
currently) in a consistent fashion (an array of base-class pointers).
Furthermore, this will be helpful if we want these things to be pointed to
from Javascript objects that may, for example, preserve their lifetime beyond
that of the element that currently owns them.
This patch also introduces a typedef for an array of refptrs to StyleAnimation
objects (and similarly for the subclass ElementPropertyTransition) to simplify
the code somewhat.
We need a basic representation of animations from which we can derive subclasses
to represent specific cases such as transitions. For now we will retrofit
ElementAnimation for that purpose hence renaming it to StyleAnimation.
This patch removes the "using namespace mozilla::layers" line from
AnimationCommon.cpp since the unified build system concatenates several files
together before compiling making using declarations like this leak into other
files potentially creating ambiguities. Previously, when we were calling
ElementAnimation, 'Animation', there were ambiguities between
mozilla::layers::Animation and this new 'Animation' class. In general, it is
probably a good idea to limit the scope of these using declarations so I've kept
that change.
This patch relocates ElementAnimation from nsAnimationManager.{h,cpp} to
AnimationCommon.{h,cpp} and in the process moves it into the mozilla::css
namespace.
ElementAnimation::HasAnimationOfProperty doesn't seem to be overridden anywhere.
I suspect it was a copy-paste mistake because the methods of the same name on
ElementAnimations, ElementTransitions, and CommonElementAnimationData are
virtual.
As part of moving towards more shared data structures for animation, this patch
makes ElementPropertyTransition inherit from ElementAnimation. At the same time
we switch from storing the target property, start/end values, start time, delay,
and timing function on the transition to the corresponding location in
ElementAnimation.
Since nsDisplayList::AddAnimationsAndTransitionsToLayer was already doing this
conversion in order to create animations to pass to the compositor thread, we
can remove the conversion code from there and just use the ElementAnimation data
structures as-is.
A number of assertions are added to verify that transitions are set up as
expected (namely, they have only a single property-animation with a single
segment). As we move to more generic handling of animations and transitions
these assertions should disappear.
When we have a backwards fill and we sample at *exactly* the start of the
animation on the next refresh driver tick, when we get to
RestyleManager::ComputeStyleChangeFor (or more specifically
ElementRestyler::CaptureChange) we notice that the style hasn't changed (since
the first frame of the animation produces the same value as the backwards fill)
and end up with an empty change list. As a result we never schedule a view
manager flush and rebuild the layer. Hence, the animation never gets sent to the
compositor thread. On the next tick we're already throttling the main thread.
This patch fixes this by applying the same approach as is used for transitions,
that is, explicitly marking which animations are running on the compositor
thread so we know if we need to trigger a layer transaction or not. This should
not only be more robust than the previous code but also facilitate aligning
animations and transitions code (bug 880596).
Jonathan Watt
Brian Birtles
David Zbarsky
L. David Baron
Ehsan Akhgari
Jan Beich