Use mozilla::dom::FillMode and mozilla::dom::PlaybackDirection
in AnimationTiming.
--HG--
extra : rebase_source : 8210d002d6f116793f439d88b0325ab6fb880048
Fix: INFO TEST-UNEXPECTED-FAIL | dom/animation/test/chrome/test_animation_observers.html | Test timed out.
By extending animation observer timeout.
--HG--
extra : commitid : GEfsdBOqqsu
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.
