Only calling VectorDrawable's mutate here will miss all the animator setup,
when the VectorDrawable has a new state.
So we just deep copy everything and setup the animators again.
b/18521582
Change-Id: Id164312750bb548f9c2d21cc0b5806cd2bafcf0d
Previously, the android:reversible flag behaves like a suggestion.
Now it is used to enforce no reverse when set to false. In this way, user can
safely setup one direction animation only.
When set to true, but AVD can't reverse , then it will show a warning.
At the same time, update the tests to show different cases, including
AnimationDrawable.
b/18413484
Change-Id: I5552c49dcbd76b0724b4d5593bce8388b27bd905
We should treat all the animator as a group, we should not start again unless
all the previous animations have stopped.
b/18320770
Change-Id: I5b0c2c165cd314745ee6c7152aea3c666e9dff10
Removes all implementations of three-arg ConstantState constructor, since
we handle mutation and applyTheme() in Resources now. Moves progress bar
tinting to android:tint attribute. Correctly implements applyTheme() and
canApplyTheme() in all drawable wrapper and container classes.
Change-Id: Ic9cb43d0d6228aa4914f3124bed234b837beaa41
This ensures that drawables are completely separated from their cached
constant states before applying a theme. After this, we can remove the
implicit (and incomplete) mutation in the clone constructors.
Also implements missing mutate() method on ClipDrawable.
BUG: 17646144
Change-Id: If0d66b0a85724d76e0a4f506758c7ba3c0aa3410
Complex animated vector drawables can be expensive to load due to
sub-optimal parsing of the String-based pathData. Suffering that penalty
every time the same drawable is loaded (such as material-themed
ProgressBars) is painful.
The new approach caches constant state of both the VectorDrawable (including
the pathData geometry) and the animators (which includes potentially expensive
path-based interpolators).
issue #17366831 Material ProgressBar taking 200+ms to inflate
Change-Id: Iba3b541e24cfce8c07f5aa9fe6aa7d7b92b2fe1c
Bug 16984007
Animated Vector Drawables were using the viewport dimensions for
calculating the allowable animation error. Instead of using viewport
dimensions, it is better to use the intrinsic dimensions. Using
the viewport dimensions meant that a small viewport (e.g. 1x1)
would mean that animation paths within would only have an accuracy
of 50% of the dimensions of the drawable.
Change-Id: Id0152eabb4effd1e50c644eea7a371b38baeb7c1
- Merge <size> and <viewport> attributes all in to top-level <vector> tag
- Indent attributes under <group> in java doc.
- Updata android:stroke to be android:strokeColor, likewise android:fill
- Instead of android:clipToPath, make this a different clip-path tag.
- Document units of the various attributes
- Add example code for defining a VectorDrawable resource
More than that:
= Refactor the code to better support clipPath as a sub-class.
= Update all the xml files to use the new attributes and clip-path tag.
TODO:
-- Remove clipToPath, since that should happen on build break Friday.
bug:16488254
Change-Id: I6db5680ef83cb26c8f064a60fc7d6e7142974b0f
At the same time, AVD is using a mutated version of VD.
And AVD won't support constant state.
Move the targetsMap down into constant state.
bug:16017895
Change-Id: I12fbc52a8719362adba9df1e0f97288decbd33b2
Currently as a hidden class.
It can support many the animations now as far as ObjectAnimator and
hierarchical group can support.
And we don't have path morphing yet.
Also support the Animator / Interpolator inflation from Context and Resources.
Change-Id: I948bbdf7373ad291171eed0b497959dce8c2edf3
