Use SetEffectNoUpdate() for the procedure of setting effect, and let SetEffect()
also calls PostUpdate(), so we can use SetEffectNoUpdate() if we don't want to
call RequestRestyle(RestyleType::layer).
MozReview-Commit-ID: CaWA34UebpH
--HG--
extra : rebase_source : d29f5ddc0b8e069293a4a69f0e821786a2c5a84a
This is a pre-patch for part 5, which is trying to make our code closer to the
spec. Some methods in KeyframeEffectReadOnly belong to AnimationEffectReadOnly,
so first, use AsKeyframeEffect() to access those keyframe-related methods, and
then add virtual methods for timing-related methods to AnimationEffectReadOnly.
MozReview-Commit-ID: 1srA1f8JYeN
--HG--
extra : rebase_source : 99a06e20a63b9c8b179fa8501690abf01271aaf4
Add mTransitionProperty and mTransitionToValue into CSSTransition, so we can
retrieve the original property and ToValue after setting a different effect.
MozReview-Commit-ID: 6sBGHkPAhGX
--HG--
extra : rebase_source : 2b209bb5cd5513899774025e18fc39d5b8268846
The previous patch in this series renamed nsCSSProperty to nsCSSPropertyID.
This patch renames nsCSSPropertySet to nsCSSPropertyIDSet accordingly.
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSPropertySet\b/nsCSSPropertyIDSet/g' -i''
Then:
hg mv layout/style/nsCSSPropertySet.h layout/style/nsCSSPropertyIDSet.h
... and finally, manually renaming nsCSSPropertySet in the include guard in
nsCSSPropertyIDSet.h.
(NOTE: Re-landing this patch on a CLOSED TREE to correctly-address the merge bustage that closed the tree.)
MozReview-Commit-ID: ASUNs7FWbKP
--HG--
rename : layout/style/nsCSSPropertySet.h => layout/style/nsCSSPropertyIDSet.h
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The merge from inbound to central conflicted with the merge from
autoland to central, it appears. Per tree rules, the commit from the
autoland repo wins and the inbound commit gets backed out.
CLOSED TREE
--HG--
extra : amend_source : 927e1cdfa8e55ccbd873d404d905caf6871c8c4f
extra : histedit_source : 07095868c3f767258e1d7d2645193bf4811b13bb%2Ca49ae5a28bf6e67298b6208ee9254c25a2539712
The previous patch in this series renamed nsCSSProperty to nsCSSPropertyID.
This patch renames nsCSSPropertySet to nsCSSPropertyIDSet accordingly.
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSPropertySet\b/nsCSSPropertyIDSet/g' -i''
Then:
hg mv layout/style/nsCSSPropertySet.h layout/style/nsCSSPropertyIDSet.h
... and finally, manually renaming nsCSSPropertySet in the include guard in
nsCSSPropertyIDSet.h.
MozReview-Commit-ID: ASUNs7FWbKP
--HG--
rename : layout/style/nsCSSPropertySet.h => layout/style/nsCSSPropertyIDSet.h
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
Add a new file, KeyframeEffectParams.h, and define the basic data
members nsString for the spacing mode.
Also, add one more argument, const KeyframeEffectParams&, to the
constructors of KeyframeEffect(ReadOnly).
MozReview-Commit-ID: I7LYlnv6LLb
--HG--
extra : rebase_source : 9aebb7b9659588674c2a954eb2ce62c827bc9830
Transitions on the compositor sometimes go further ahead while the
main-thread is busy. When the transition on the compositor is replaced by a
new one, until now we calculate the current position of the old one with the
most recent refresh time. But if the replace is done on a busy frame, the
calculated position will be far from the real position on the compositor.
As a result, we can see jumping transitions after busy frames.
To mitigate this issue, we should calculate a plausible current position of
the old one with the current time just before sending the new transition to
the compositor, i.e., after all JS callback works have done.
The plausible value is stored into KeyframeEffectReadOnly::mProperties, not
into mKeyframes. If we store the value into keyframes,
KeyframeEffectReadOnly::GetKeyframes() will return a different values after
busy frames.
Note that with this patch getComputedStyle() does not return the plausible
value because this patch does not affect styling process. getComputedStyle
issue will be fixed in bug 1273834.
MozReview-Commit-ID: B85kIx6qeyy
--HG--
extra : rebase_source : d19fd18a78bc1ce7820301f2b98832f0ba3dcd8e
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.
