The behavior of unthrottling in case of not current animations there is the
same as on current trunk.
There are two cases to reach there I can think of:
a) 0s duration time and fill-forwards animation
b) Calling pause() after fill-forwards animation finished.
I can provide these automation tests once bug 1222326 is fixed.
The preference check has been removed from CanThrottleTransformChanges
because we already perform that check that when deciding if we should run
an animation on the compositor (in CanPerformOnCompositorThread, as called
by GetAnimationsForCompositor). Hence if the "is running on compositor" flag
is true, we can assume the preference is set (or was set when we decided to
put the animation on the compositor-- we don't worry about pulling the
animation off the compositor immediately if the preference changes while
it is running)
Based on AnimationCollection::CanAnimatePropertyOnCompositor.
The first argument has been changed to nsIFrame* so that we don't need to
get style frame for CanAnimateTransformOnCompositor again.
If this patch (and part 9) is an overkill to throttle animations having both
of properties, one can be run on compositor and another can not be, a test
case in test_running_on_compositor[1] will fail.
The test case is for an animation which has transform and background-color
properties.
Animation::CanThrottle() returns true
(then, AnimationCollection::CanPerformOnCompositorThread() returns false)
on current trunk in the test case.
Animation::CanThrottle() returns false with this patch in the test case.
If the test passes, it proves the transform animation is running on compositor
in both cases.
[1] http://hg.mozilla.org/mozilla-central/file/6c7c983bce46/dom/animation/test/chrome/test_running_on_compositor.html#l77
Do some minor revisions in struct ComputedTiming.
1. Use Nullable<double> mProgress, so remove the static const kNullProgress.
The generated ComputedTimingProperties dictionary uses "Nullable" variable,
so we replace the origin type in ComputedTiming to make it more consistent
with that in ComputedTimingProperties dictionary.
2. Use scoped enums for AnimationPhase.
--HG--
extra : rebase_source : 31280c867a30e7bcdcfe831cbc72ca08c8ddc762
Add two dictionaries into AnimationEffectReadOnly.webidl:
1. AnimationEffectTimingProperties
2. ComputedTimingProperties
And then re-generate this class.
--HG--
extra : rebase_source : 81b2a3c08453cabcb2ac1334e6d4bde2c1bafeea
The Animation.pause() method operates asynchronously since, if the animation is
currently running on the compositor, we should wait for the animation to stop
on the compositor before establishing the pause time. Otherwise, if the
compositor is ahead of the main thread and we use the main thread's notion of
the current time to establish the pause time, the animation will jump backwards
when we take it off the compositor.
This pause time is represented using the "hold time".
However, when we have a finished animation, its current time is not advancing
but rather its current time is fixed to its end time. This too is represented
using the hold time. As a result, if we pause a finished animation we should
not update its hold time (by calculating the current time from the start time)
but just continue to use the existing hold time. This is true of any other
situation where we might have set the hold time before or during pausing.
In a subsequent patch, we will have another struct like
KeyframeValueEntry, but storing an StyleAnimationValue and an
ComputingTimingFunction object (not a pointer). So we split
KeyframeValueEntry into two, retaining the KeyframeValueEntry name for
the base class and naming the current one KeyframeStringValueEntry.
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
Animation::Tick contains special handling to cope with pending ready times
that are in the future. This was originally introduced to cope with the
situation where we are called multiple times per refresh-driver tick.
As of bug 1195180, Animation::Tick should no longer be called multiple
times per refresh driver tick. It would seem, therefore, that we no longer
need to check for a future time. However, since introducing this check, the
vsync refresh driver timer has been added which means that we can still have
a recorded time from TimeStamp::Now that is ahead of the vsync time used to
update the refresh driver. In that case, however, rather than waiting for the
next tick, we should simply clamp that pending ready time to the refresh driver
time and finish pending immediately.
This patch also updates one of the tests for reversing. With this updated
behavior we can sometimes arrive at a situation where when an Animation starts
and its ready promise resolves, its currentTime is still 0. If we call
reverse() at this point on an animation with an infinite active duration it
should throw an InvalidStateError. To avoid this situation, this test makes
sure we wait an extra frame before calling reverse().
This patch renames AnimationCollection::mNeedsRefreshes to indicate that it
no longer has any relationship to whether or not we observe the refresh driver.
We need to do this so effects can query their owning animation for the current
time and avoid falling out of sync. Furthermore, this pointer is needed
for a number of other bugs (e.g. bug 1166500 comment 12, or bug 1190235)
anyway.
Since getFrames() must gather all properties set at a given keyframe
offset time for a given easing function, we need to provide a total
ordering for ComputedTimingFunction objects. Until the spec defines how
to do this, we sort first by NS_STYLE_TRANSITION_TIMING_FUNCTION_*
value, then second by the four values in a cubic-bezier() function (in
order) or the integer and optional keyword in a steps() function.
Because we don't support automatic spacing of keyframes yet,
ComputedKeyFrame.computedOffset is always the same as Keyframe.offset.
Another assumption made is that the value of easing for a Keyframe
object at 100% should be the same as the value from the previous
Keyframe for the same property. An alternative would be to leave off
easing from that Keyframe, which would need the default value for that
IDL dictionary member removed (otherwise it would always be set to
"linear").
Since Keyframe.easing should reflect the {transition,animation}-timing-
function value relevant to each keyframe, we'll need to store on
nsTimingFunction the specific timing function value that was used, and
copy it down into ComputedTimingFunction for
KeyframeEffectReadOnly.getFrames() to access. This includes storing
whether the optional start/end keyword in a steps() function was
specified.
This patch adds a test that even when we seek from being irrelevant to another
state where we no longer need ticks that we still spin the refresh driver
in order to queue and dispatch an animationstart event.
Currently AnimationTimeline stores animations in a hashmap which means that
when we go to iterate over those animations to tick them we will visit them
in an order that is non-deterministic.
Although many of the observable effects of ticking an animation (e.g. CSS
animation/transition events, mutation observer events) are later sorted so that
the result does not depend on the order in which animations are ticked, this is
not true for in all cases. In particular, the order in which Animation.finished
promises are resolved will vary depending on the order in which animations are
ticked. Likewise, for Animation finish events.
Furthermore, it seems generally desirable to have a deterministic order for
visiting animations in order to aid reproducing bugs.
To achieve this, this patch switches the storage of animations in
AnimationTimeline to use an array instead. However, when adding animations
we need to determine if the animation to add already exists. To this end we
also maintain a hashmap of the animations so we can quickly determine if
the animation to add is a duplicate or not.
Now that DocumentTimeline observes the refresh driver we can use regular
ticks to remove unnecessary animations.
We do this because in a subsequent patch, in order to provide deterministic
enumeration order when ticking animations, we will store animations in an array.
Removing an arbitrary element from an nsTArray is O(n) since we have to search
for the array index first, or O(log n) if we keep the array sorted. If we
destroy a subtree containing n animations, the operation effectively becomes
O(n^2), or, if we keep the array sorted, O(n log n). By destroying during a
tick when we are already iterating over the array, however, we will be able
to do this much more efficiently.
Whether an animation is newly associated with a timeline, or is disassociated
from a timeline, or if it merely has its timing updated, the behavior
implemented in this patch is to simply make sure we are observing the refresh
driver and deal with the animation on the next tick.
It might seem that we could be a lot more clever about this and, for example, if
an animation reports NeedsTicks() == false, not start observing the refresh
driver. There are various edge cases however that need to be taken into account.
For example, if a CSS animation is finished (IsRelevant() == false so that
animation will have been removed from the timeline), and paused
(NeedsTicks() == false), and we seek it back to the point where it is relevant
again, we actually need to observe the refresh driver so that it can dispatch an
animationstart event on the next tick. A test case in a subsequent patch tests
this specific situation.
We could possibly add logic to detect if we need to fire events on the next tick
but the complexity does not seem warranted given that even if we unnecessarily
start observing the refresh driver, we will stop watching it on the next tick.
This patch removes some rather lengthy comments from
AnimationTiming::UpdateTiming. This is, in part, because of the behavior
described above that makes these comments no longer relevant. Other parts are
removed because the Web Animations specification has been updated such that a
timeline becoming inactive now pauses the animation[1] so that the issue
regarding detecting timelines becoming active/inactive no longer applies
since animations attached to an inactive timeline remain "relevant".
[1] https://w3c.github.io/web-animations/#responding-to-a-newly-inactive-timeline
