Add a new API in nsTransitionManager, so we can cancel transitions for a
specific element easily. The purpose of this API is for cancelling transitions
without dispatching the event.
--HG--
extra : rebase_source : 07483aebb8513dcd39c5e1805480dcbe6d3945b3
Although we know that the animation properties will always be filled in for
a transition in the cases where we need to query them (going forward we will
have a situation where an animation may only have frames, not properties, but
that will only happen when the animation isn't attached to an element or the
element is not attached to a document, but we don't run animations in that case
and cancel existing ones when we enter that state so although they *can* enter
that state, we'll never run these methods on them when they do), we still want
to move towards making frames the primary unit for interacting with animation
values since frames always exist and represent the public interface.
Ultimately it would be good to make the properties array on
a KeyframeEffect(ReadOnly) an encapsulated detail so that we can freely change
their structure (e.g. segments might not be the best setup, it might be better
to just have arrays of free-standing values to avoid the duplication of
values when segments are continuous).
This patch removes or encapsulates a few references to properties and
simplifies the code at the same time.
MozReview-Commit-ID: 3II36SYVoRE
By moving GetAnimationCollection to AnimationCollection itself, we can remove
a bunch of virtual methods on the animation managers, simplify call sites,
and provide better type safety by ensuring a correspondence between element
property names and concrete animation types.
One change in behavior, however, is that in doing this we can no longer
add any newly-created AnimationCollection to the corresponding manager's linked
list of collections inside GetAnimationCollection. Instead we take a bool
outparam to indicate if a new collection was created and leave managing the
linked list to the manager. This is just a temporary measure, however, since
by the end of this patch series will will eliminate this linked list altogether
along with this flag.
MozReview-Commit-ID: 1jsc4QcmVDg
This patch templatizes the type of Animation stored in an AnimationCollection.
This allows us to remove a number AsCSSAnimation() calls in nsAnimationManager.
This patch also removes the AnimationPtrArray typedef. In its place we
introduce OwningCSSAnimationPtrArray and OwningCSSTransitionPtrArray but we
don't use these as widely. There was some comment previously that the typedefs
in animation code make it hard to read, particularly when these typedefs don't
make it clear if the data type is an owning reference or not.
In doing this we need to templatize CommonAnimationManager as well and move the
implementation of its (few) methods to the header file. We may be able to
remove the need for templatizing CommonAnimationManager later in this patch
series depending on how we ultimately decide to handle the lifetime of
AnimationCollection objects.
CommonAnimationManager::GetAnimationCollection is a bit messy but this will be
significantly tidied up in subsequent patches in this series.
MozReview-Commit-ID: 3ywatY53pRR
In this bug we will trim off unnecessary functionality from the animation
managers and make AnimationCollection into an independent data type
so in this patch we separate it into its own file.
It is also generally easier to navigate the source code and eliminate
cyclic dependencies between header files when there is a rough
correspondance between class names and file names (e.g. rather than having
#include "AnimationCommon.h" // For mozilla::AnimationCollection).
This patch also makes a few simplifications to include dependencies since
they're a bit of a mess (making it hard to move code around). The changes to
IncrementalClearCOMRuleArray.cpp are due to the changes to the unified build
introduced by adding AnimationCollection.cpp exposing a missing include from
that file.
We store the original value of duration in AnimationTiming, and add
computed duration in ComputedTiming, so both the Timing model and
AnimationEffectTimingReadOnly can get what they want.
By the way, replace mIterationDuration with mDuration.
--HG--
extra : rebase_source : f8e1fd648572e6d7b1cbecc2ac1888a2f74bbc7e
Introducing an enum will simplify further patches in this series by providing
a common vocabulary for this distinction.
--HG--
extra : rebase_source : 4afbd358a401853df3ad401f2b1c3454ccff26cd
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
This patch also reworks the dispatch of events in nsRefreshDriver. Previously
the refresh driver would dispatch the transition events for all subdocuments
then the animation events. This arrangement is complicated and not obviously
necessary. This patch simplifies this arrangement by dispatching transition
events and animation events for each document before proceeding to
subdocuments.
--HG--
extra : rebase_source : ed9147de4a4b5f36e444bdab82e45ee2143e5be8
In order to sort between events that have the same timestamp we use the
sort order of the corresponding animations so we need to store a pointer
to the animation along with the event.
--HG--
extra : rebase_source : 2767157135abd5a094d856410cd9c70e46a33b68
This patch lines up the parameters of AnimationEventInfo and
TransitionEventInfo constructors so that they are more logical and consistent.
Specifically, it groups the element and pseudo type together since they
form a logical pair denoting the event target. For AnimationEventInfo this
patch also places the type of event before the common event parameters since
the event type seems to be more significant.
This patch also performs some miscelleaneous housekeeping: removing some
unnecessary namespace prefixes, whitespace fixes, and making
TransitionEventInfo use the same concrete type to store the target element
as AnimationEventInfo (dom::Element instead of nsIContent).
--HG--
extra : rebase_source : ce6935f74f31dffadce4d0e7d4fa8859ec213740
In the new composite order arrangement CSSAnimations and CSSTransition have the
following life-cycle:
1. Animation created by markup
=> composite order determined by markup
(e.g. CSS animations use tree order and animation-name order;
CSS transitions use transition trigger order)
2. Animation cancelled by changing markup
=> composite order is undefined
3. Animation is played again using the API
=> composite order is defined by when the animation is first played.
Another way of saying this is that, at the point when the animation is
played, it is appended to the "global animation list".
4. Animation is subsequently cancelled / played => no change
We need a way to know when we are going from 2 to 3. It would seem like we
could do that by setting mAnimationIndex to some sentinel value while it is
in 2. However, even when in 2, although the spec doesn't define the composite
order animations at this point (from an API point of view you can't access these
objects and they don't contribute to style so it doesn't need to be defined), we
sometimes will need to establish an order.
This can happen, for example, when an animation queues events and then is later
cancelled before the events are dispatched. Because we sort events based on
their associated animation at the time of dispatch (for performance reasons) we
need a deterministic order for these idle animations.
We do that (in a subsequent patch in this series) by setting mAnimationIndex
when we transition from 1 to 2. That is, these idle animations are effectively
ordered by when they became idle (which always happens in a deterministic
fashion).
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.
nsTransitionManager::WillRefresh and nsAnimationManager::WillRefresh are now
identical and all methods they call exist on CommonAnimationManager so we
can unify them there.
The implementations of FlushAnimations and FlushTransitions should now be all
but equivalent so this patch combines them into a single implementation on
CommonAnimationManager.
Regarding some of the minor differences between the two methods:
* The combined implementation drops the check for an empty list of collections
found only in FlushTransitions. This seems like a very minor optimization
that could possibly cause us to fail to unregister from the refresh driver
if we forgot to do so when removing the last collection.
* The combined implementation uses the loop implementation from FlushAnimations
since it is more compact.
This patch also removes the extra nested scope since it doesn't seem necessary.
This patch causes transition events to be dispatched as a separate step after
sampling the transitions. Eventually this will allow us to sample transitions
from their timeline (independently of where they came from and in potentially
any order) by separating the concepts of sampling and event dispatch.
This patch moves the logic for queueing events out of the logic for flushing
transitions making it a separate step. It still doesn't delay the dispatch of
those events into a separate step, however. That is done in a subsequent patch.
This patch also makes sure to clear any queued events when the nsPresShell that
owns the transition manager is destroyed. We don't expect CSSTransition::Tick to
be called anywhere except nsTransitionManger::FlushTransitions so there
shouldn't be any orphaned events but for completeness it seems best to add this
now. (Later, when we tick transitions from their timeline we will need this.)
This patch introduces a separate flag to CSSTransition for tracking if a
transition is newly-finished so we can correctly dispatch the transitionend
event. Although, this may seem to be redundant with the "IsFinishedTransition"
we also track, that state will soon be removed in bug 1181392 and hence this
flag will be needed then.
Note that Animation already has flags mIsPreviousStateFinished and
mFinishedAtLastComposeStyle which would appear to be similar however,
- mIsPreviousStateFinished will be removed in bug 1178665 and is updated more
often than we queue events so it is not useful here.
- mFinishedAtLastComposeStyle is used to determine if we can throttle a style
update and is also updated more frequently than we queue events and hence
can't be used here.
Once we guarantee one call to Tick() per frame we may be able to simplify this
by tracking "state on last tick" but for now we need this additional flag on
CSSTransition. CSSAnimation has a similar flag for this
(mPreviousPhaseOrIteration) which we may be able to unify at the same point.
This simply uses the DelayedEventDispatcher in place of the previous array of
TransitionEventInfo objects. Doing the actual delayed dispatch is performed in
a separate patch.
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.
