This is reverting the revert of what reverts the revert of the original
implementation. Fourth revert is a charm!
This reverts commit df7fdb1e0b.
Change-Id: I6fc3a5accfd8b79c3da31bbc101ad9e9b4d6e7dd
This CL runs VectorDrawable animation on RenderThread. The changes in this CL
include:
- Convert all the animators in AnimatorSet for AVD into a set of RenderNodeAnimators.
- Hook up the new animators with RenderThread
- Add drawOp in RecordingCanvas for drawing VD so that during the animation
on RenderThread, all the property changes on VD can be reflected on the screen.
TODO:
- Implement reverse and reset for AVD.
Change-Id: I2df1d754f2db0ad098d9c15dde4bb2bdfafc2315
There is logic in PVH.setupValue() that sets the value of
the appropriate keyframe from a Property, if that Property object
exists for the animator. But after that is done, it goes ahead and sets
the same keyframe value based on the getter for the target object.
This is not only redundant; it is wrong (in the odd situation in which
a getter would return something different than Property.get()).
The solution is to return early once we've set the value with the
Property object.
Issue #26471646 PropertyValuesHolder uses reflection in setupValue when a Property is being used
Change-Id: I12634a25661400f13f44872ba17625b32e93ca19
Introduced PathData in Java, which is effectively a thin layer around the
native instance. PathData holds the verbs and points which is being used
in path morphing/interpolation. The verbs and points can be interpreted
into skia path commands, which is now done in native and therefore saves
a handful of JNI calls during path creation.
Removed the old PathDataNode mechanism and changed the PathEvaluator
to use PathData instead.
Also added tests and a microbench. Also ran CTS tests for VectorDrawable
and AnimatedVectorDrawable, and passed all of the existing tests.
Change-Id: Ia166f5172ff031fe18b154327967f911a62caec1
Total duration is the total amount of time an animation takes from
start to finish. It include start delay (if any), child animation
sequence, accounting for repeat.
Change-Id: Id5b36a63c02e25586aefd38612aa5867492e1adb
mPlayingBackwards is confusing when placed next to mReversing.
One means the overall direction of animation playing, the other
indicates the direction of playing in the current iteration.
mCurrentIteration and mPlayingBackward are redundant together,
as the latter can be derived from the former, given the overall
direction of animation playing. Redundant variables pose risk of
getting out of sync and therefore are refactored out in this CL.
Instead, an overall fraction that ranges from 0 to mRepeatCount + 1
was introduced. It can capture both the current iteration and the
fraction in the current iteration. It gives a much better idea of
the overall progress of the animation.
Change-Id: Ic0ea02c86b04cfc01c462687d1ebbd46184cbab7
Return a valid value for the current play time if the animator has
been seeked to a play time or fraction, but not yet started.
Issue #24717972 animator.getCurrentPlayTime() is all messed up
Change-Id: I15f1329b65410b4b0366a23a3419b5987305a865
This CL maintains the behavior that animators without any
start delay will get started right away, instead of being delayed
to the first frame as it was in the previous refactor.
Bug: 23825781
Change-Id: I7873bc6c7a761c1b4d48ee5e17af631b359fd676
isRunning() for an Animator indicates whether an animator has gone
past its start delay and not yet finished. As a subclass of Animator,
AnimatorSet should follow the same principle. The implemention prior
to this CL returns whether any child animation is running, which is
inconsistent with the javadoc for isRunning() and general behavior
for Animator.
Change-Id: Iece814dfcd609ee292dbc00bd55dc64c7bda8e57
end() and cancel() in ValueAnimator will trigger onAnimationCancel
or onAnimationEnd callback on its listeners. If additional end()
or cancel() request comes from the callback, a loop will be formed.
Therefore, we need to mark when the end is reuqested so we do not
process end() or cancel() request multiple times during one animation
run, and also effectively terminate the loop.
Bug: 23596652
Change-Id: Iefb69eb8969071b43124c09d7cccbe9ff5ba5dcc
This CL includes the following changes:
1) Remove redundant field mPlayingState in ValueAnimator.
2) Refactor AnimationHandler so that all of its interaction with Choreographer
is through an interface. A custom provider that implements this interface can
be plugged in and provide timing pulse that are independent of Choreographer.
3) Better encapsulate AnimationHandler and ValueAnimator. Interaction between
the two is done through register/unregister frame callbacks as well as
AnimationFrameCallback interface.
4) Change how animation delay is handled.
Change-Id: Icd49f727321c362dab49b5b33815333c9ea559e0
Each animator's total druation is cached in the set, so that when
their duration changes, the dependency graph will be updated to
reflect the change.
Change-Id: I677bc289f2ba430466f2d90ebc14368cb7b75118
This CL fixes the bug where when there're AnimatorSet inside of
AnimatorSet, incorrect AnimatorListeners get notified of the
Animator's lifecycle events.
Bug: 22940651
Bug: 22954352
Change-Id: I2bf66413d54dcfc75dc7fa779e723443763a30a5
This refactor changes how relationships (i.e. with/after/before)
among Animators in an AnimatorSet are represented. Specifically,
a directed graph is used: parent-child indicates sequential
relationship, and siblings will fire simultaneously.
This CL also fixed the issue where start delays for Animators that
play together are not handled correctly.
Bug: 11649073
Bug: 18069038
Change-Id: I5dad4889fbe81440e66bf98601e8a247d3aedb2e
Behavior is different than spec'd for one-shot animators, clarified
docs to reflect that.
Issue #21087798 better docs for isStarted()
Change-Id: I499a5d52cf02ef715acb6ae0635ede4328c93de8
Previously, changes have been made to infer value types for
PropertyValuesHolder when no value type is defined. This CL applies
the same inferring logic to ObjectAnimator too.
Bug: 21645431
Change-Id: Ifdf163a7d32da990dc2281080f87f94c0df0e9ce
This fix is to take advantage of ArrayMap, which is a key-value
mapping data structure that is more memory efficient than HashMap.
Bug: 11604254
Change-Id: I57006880de570a4d7f3899e274cf0a06355d116b
Themes now use an array of applied styles rather than a String to store
their history. They are keyed based on a hash code computed from the
history of applied styles. The themed drawable cache has been abstracted
out into its own class.
Also updates system context to use DayNight as the default and ensures
that GlobalActions uses the correct context, which exercises the change.
CTS tests have been added in another CL.
Bug: 20421157
Change-Id: I9eb4b7dffd198ad24d02f656eaf0839570b59caa
Previously, an OnPreDrawListener was added to clean things up, including
removing the listener, after animations are started.
But if the view is detached before that listener is called, the
listener will remain on that ViewTreeObserver.
This change adds an OnAttachStateChangeListener to perform that cleanup
step when the view is detached, just in case.
Issue #20824645 Leak in LayoutTransition
Change-Id: I264812f8e02dda673789712ba83d208e87cdc5a4
Duration scale based on screen size was using the area of the screen
excluding system bars to compare with our reference device's screen
size. This caused the following issues:
1) On baseline device (i.e N5) a scaling factor that is not 1 will be
applied to the duration.
2) Scaling on the same device will be different in landscape vs.
portrait, as the system bars take different amounts of space in
different orienations.
This CL fixes both of the above issues.
Bug: 20309042
Change-Id: I9d1d0a471d968bee1330b80f0f69a0066d6a1860
