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.
Now that an animation's delay is part of AnimationTiming--the struct we pass to
GetComputedTimingAt--it makes sense to act on it in GetComputedTimingAt.
This also happens to bring the procedures here closer to the algorithm
definitions in Web Animations.
As part of this refactoring, this patch converts ElementAnimation::IsRunningAt
to use GetComputedTiming since the previous approach no longer works now that
GetLocalTimeAt (nee ElapsedDurationAt) no longer handles delays. This also
removes duplicated logic.
Also, previously ElapsedDurationAt would assert if called on a finished
transition since TimeDuration's - operator wouldn't like the null mStartTime.
This patch adds an assertion for this case to GetLocalTimeAt to ease debugging.
This patch is the first part in preparing the way to merge ElementTransitions
with CommonElementAnimationData (which we'll eventually rename to something
nicer).
Here we move mTiming from CommonElementAnimationData to the AnimationTiming
struct. While this is not strictly necessary in order to do the later
refactoring it makes it simpler since it:
- Divides time calculation into calculation based on dynamic play state (the
responsibility of animation players in Web Animations terms) and static
author-specified timing parameters (a property of animations in Web Animations
terms).
- In future we will probably put animations on the compositor during their
delay phase so we will want the delay to be present in the AnimationTiming
struct then.
- Makes AnimationTiming line up with the dictionary of the same name in Web
Animations.
This patch removes the check that skipped queueing events for animations
without keyframes since the spec indicates such animations should dispatch
events.
There is a further correctness fix here for the case where a keyframes rule
is modified using the CSSOM so that it becomes empty. Previously when we
came to create the new animation rules we would end up setting
ElementAnimations::mNeedRefreshes to false since we check if the keyframes
rule is empty and if it is we would skip all further processing (including
setting mNeedsRefreshes).
That means that:
(a) We may end up unregistering from the refresh observer so we would never
dispatch the end event for such an animation.
(b) If the animation was running on the compositor we may never remove it from
the compositor or may not do it in a timely fashion.
To fix both these problems, this patch removes the check for an empty keyframes
rule so that mNeedsRefreshes is set in this case.
This patch also makes ElementAnimation::ActiveDuration a static method that
takes timing parameters as an argument. This is so that this method can be
used within ElementAnimations::GetComputedTimingAt (a static method) in a
future patch.
We could also make ActiveDuration() a method of AnimationTiming. I suspect
this logic belongs together in ElementAnimation however.
In a future patch we could also add the active duration to the ComputedTiming
struct which would simplify the only other place this is currently used
which is ElementAnimations::GetEventsAt.
Also shuffle the initialization of members in
nsAnimationManager::BuildAnimations to roughly match the order in which they
are declared (with the exception that mPlayState needs to be set before calling
IsPaused() which is used to set mPauseStart).
This was only needed when we were inspecting the returned time fraction but now
that we inspect the phase it's not necessary to force the fill mode to "both".
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 shuffles the code in ElementAnimations::GetEventsAt to make it easier
to follow.
It also removes a check for whether or not the animation is paused.
Previously we would not dispatch events if the animation was paused and in its
active phase (but we would if the animation had finished). There doesn't seem to
be any reason for this. If the animation was paused between the last sample and
the current sample and the boundary of an iteration also occurred in that time
then I expect we should dispatch that event. Removing this check for the pause
state does not cause any tests fail.
Separating out the event logic here makes it clear that we do not dispatch start
events in the situation where one sample falls before the active interval and
one sample falls after it (filed as bug 1004361). This patch adds a comment to
this effect.
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 the FillsForwards/FillsBackwards methods previously defined on
ElementAnimations to the structure contain the fill mode: AnimationTiming. It
also changes GetPositionInIteration to use these methods.
Introduces a struct to store timing parameters for passing to
GetPositionInIteration. In future this struct is expected to be expanded to
include other timing parameters as well (based roughly on Web Animations'
"Timing" interface, hence the name AnimationTiming).
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.
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.
Both ElementPropertyTransition and ElementAnimation specify an IsRunningAt
method which have the same purpose but with two subtle differences:
a) ElementPropertyTransition::IsRunningAt checks if the transition is a removed
sentinel and if so returns false. This patch adds a check for a null start time
to IsRunningAt since I think in future we will want to allow null times in
various places to represent, for example, animations that are not connected to
a timeline. (However, ultimately we will probably not allow start times on
*animations* to be null, only on their associated player.)
Should we later use a different mechanism for marking sentinel transitions (e.g.
a boolean flag) this method should still be correct as it checks if aTime is
inside the transition interval before returning true.
b) ElementPropertyTransition::IsRunningAt returns false if the transition is in
the delay phase, that is, waiting to start. This patch changes this behavior so
that transitions are considered running even if they are in the delay phase.
This brings their behavior into line with animations and removes the need for
the ElementPropertyTransition::mIsRunningOnCompositor since it is only used to
determine when a transition in the delay phase has begun.
ElementAnimation::IsRunningAt also handles pause state and iterations but this
logic should still be correct for transitions which, in this area, only use
a subset of the functionality of animations since their pause state is always
playing and their iteration count is 1.
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).
Animations with a delay are not put on the compositor thread until the end of
the delay phase. However, there is currently nothing that explicitly triggers
this transaction. It may occur due to flushes that arise from UI events but it
is not guaranteed.
This patch detects the end of a delay phase and turns off throttling for that
sample. It re-uses the mLastNotification member which is not ideal but
a subsequent patch in this queue removes this and replaces it with the approach
used for transitions.
This changes the behavior of the CanPerformOnCompositorThread methods of
both ElementAnimations and ElementTransitions to check that the
respective animations or transitions are actually running. This is ok
because:
- The main caller is nsLayoutUtils::HasAnimationsForCompositor, and all
of its callers pretty clearly want the more restricted behavior (they're
concerned with layer activity)
- The only other callers of these functions are
nsAnimationManager::FlushAnimations and
nsTransitionManager::FlushTransitions (determining when to do
throttling), nsAnimationManager::GetAnimationsForCompositor (whose
only caller,
nsDisplayListBuilder::AddAnimationsAndTransitionsToLayer, also checks
IsRunningAt). I think these also all want or are fine with having
the IsRunningAt check.
As to the actual changes:
- In the animation manager, I think it's a mistake that
ElementAnimation::IsRunningAt didn't already check
mIterationDuration, since we throw out animations with a bad
iteration-duration in ElementAnimations::EnsureStyleRuleFor. So this
makes that change as well.
- In the transition manager, IsRunningAt already checks
!IsRemovedSentinel().
I've confirmed in gdb on a device that this fixes the repeated
nsIFrame::SchedulePaint calls that were the symptom of this bug.
I believe this patch also makes it so that a short animation of a
property that can't be animated on the compositor doesn't prevent the
entire duration of the animation of a property that can from being
throttled (having the main thread style updates suppressed).
Patch co-authored by Emmanuele Bassi <ebassi@gmail.com>
This defines a CSSVariableDeclarations class that holds a set of
variable declarations. This is at the specified value stage, so values
can either be 'initial', 'inherit' or a token stream (which is what you
normally have). The variables are stored in a hash table. Although
it's a bit of a hack, we store 'initial' and 'inherit' using special
string values that can't be valid token streams (we use "!" and ";").
Declaration objects now can have two CSSVariableDeclarations objects
on them, to store normal and !important variable declarations. So that
we keep preserving the order of declarations on the object, we inflate
mOrder to store uint32_ts, where values from eCSSProperty_COUNT onwards
represent custom properties. mVariableOrder stores the names of the
variables corresponding to those entries in mOrder.
We also add a new nsCSSProperty value, eCSSPropertyExtra_variable, which
is used to represent any custom property name.
nsCSSProps::LookupProperty can return this value.
The changes to nsCSSParser are straightforward. Custom properties
are parsed and checked for syntactic validity (e.g. "var(a,)" being
invalid) and stored on the Declaration. We use nsCSSScanner's
recording ability to grab the unparsed CSS string corresponding to
the variable's value.
This also changes the functionality a little bit to track independent
per-property mutation counts and independent "content active" status.
--HG--
extra : rebase_source : e69b8e7a95d36720bd38d74f0789ede603e58a09
This patch does the following:
* Move nsIFrame::IntrinsicSize to mozilla::IntrinsicSize so that it can
be forward-declared.
* Move a number of templated inline nsLayoutUtils methods to nsIFrame.
* Use mozilla::layout::FrameChildListID instead of the
nsIFrame::ChildListID typedef in nsLayoutUtils.h.
* Move nsReflowFrameRunnable to its only user, nsProgressMeterFrame.cpp.
* Make a number of functions requiring nsIFrame.h out-of-line.
* Remove the nsIFrame.h #include from nsLayoutUtils.h and add it to the
places which require it implicitly.
The fixes to the miniflush code
(nsTransitionManager::UpdateThrottledStyle and UpdateAllThrottledStyles)
fix the case where we constructed totally incorrect style contexts for
outer table frames (which have special style contexts inheriting from
the table frame) during the miniflush, leading to inconsistent style
data and other bad things, when we should have been touching the style
on the table frame instead.
The fixes to the other OMTA codepaths lead to layer tests being
performed on the same frame that the styles will be applied to, and
probably fix real bugs (which would occur when animating opacity or
transform on a table).
The fixes to the miniflush code
(nsTransitionManager::UpdateThrottledStyle and UpdateAllThrottledStyles)
fix the case where we constructed totally incorrect style contexts for
outer table frames (which have special style contexts inheriting from
the table frame) during the miniflush, leading to inconsistent style
data and other bad things, when we should have been touching the style
on the table frame instead.
The fixes to the other OMTA codepaths lead to layer tests being
performed on the same frame that the styles will be applied to, and
probably fix real bugs (which would occur when animating opacity or
transform on a table).
Brian Birtles
Birunthan Mohanathas
Masayuki Nakano
L. David Baron
Nicholas Cameron
Cameron McCormack
Robert O'Callahan
Phil Ringnalda
Wes Kocher
Markus Stange
Ehsan Akhgari
Catalin Iacob