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.
