This CL changes the target of VD specific animators to VectorDrawable,
instead of RenderNode. The benefit of doing so is that animators can
now detect whether the animation is meaningful by checking whether
their VD target is in the display list. If not, that means the VD is
not drawing for the current frame, in which case we can be smarter
and more power efficient by removing the animator from the list and
posting a delayed onFinished listener callback.
By setting VD as the animation target, when an ImageView decides to
update its drawable from one AVD to something else, we'll be able
to detect that the previous AVD is no longer in the display list,
and stop providing animation pulse to the stale AVD, which is
something we couldn't do previously. This change also
handles the case where one AVD instance could be drawn in two
different views.
Bug: 27441375
Change-Id: Iaad1ed09cfd526276b95db0dd695275c28e074e8
When mutating vector drawables, we need to not only copy over
the VD tree structure, but also the properties of the VD tree,
such as alpha.
Bug: 28974071
Change-Id: I265e7e3cb92455b876cae248bcb9811230cb34f9
There are two parts to VD's native allocation:
1) VD's internal data structure (i.e. groups, paths, etc that make
up of the VD tree). This structure can change, when a VD is used
to load a different drawable resource.
2) Two bitmap caches, not both of which will necessarily be allocated
The size of the bitmap cache depends on canvas matrix and drawable
bounds, and therefore can often change.
We need to count the native allocation from the above against Java heap.
Bug: 26269056
Change-Id: If833aedcf7f3efe00ea73a41ddccb1b48066ffd8
VD tree is ref-counted in both Java and native. VD's child nodes are
entirely owned by the native tree, as VD nodes in native should outlive
its Java counterparts, with one exception: when there's an infinite UI
animator running on VD, the animator may have weak reference to a few
child nodes. In the case of hidden animator running infinitely, the child
nodes would keep getting the animation pulse while the rest of the tree
would have been destroyed. To prevent the setters triggered by animation
from calling into native, we need to check whether the tree is still
valid before going down into JNI.
Bug: 28104172
Change-Id: Ie9d4bf3898c0c23e620a4747624d24b8ab779743
Previously we were using native config flags in some places that expected
Java flags, and vice-versa. All usages of config flags are now annotated
to ensure we're using the right type.
Cleans up annotations on most methods that were touched.
Bug: 21161798
Change-Id: Ifd87dfb12199fc8258915d8a510e03ddb681ca89
static VectorDrawable should be returning Transparent while root alpha is 0.
AnimatedVectorDrawable running on RenderThread now, and the opacity should
be conservatively set as Translucent.
http://b/27554766
Change-Id: I9a78696cab94f10ba40a733cc9c00f1c2d7ebb7f
Also added API check so that for pre-N we ignore invalid VD animation,
in order to avoid breaking old apps.
Bug: 26975469
Bug: 26949340
Change-Id: I498539ad6a05de3d886e7dcdc8a167e78333ab11
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
Add ComplexColor interface for both GradientColor and ColorStateList.
Set up constant state, factory, theme attrs for GradientColor, while
refactoring the ColorStateList's similar code. (Functionality in CSL should
be the same).
Support themeing in both the root and item level in GradientColor.
For example, both startColor in <gradient> tag or color in <item> tag can
have theme color.
Add tests for both simple and complex cases with themeing etc.
Hook up the native VectorDrawable implementation using 2 extra JNI calls for
simplicity. Such calls only happen at inflate and applyTheme call.
b/22564318
Change-Id: Ibdc564ddb4a7ee0133c6141c4784782f0c93ce0e
- Refactored VPathRenderer & VectorDrawableState
- Moved all the VD rendering into native
- Set up hooks for VD's property changes in JNI for animated VD
TODO: JNI calls can be further reduced when we convert the animation
in AVD to use RenderNodeAnimator, in which case animation will be
driven from native and therefore most of the JNI hooks for changing
VD's properties during animation will no longer be needed.
Change-Id: I52021f4d7bea057b83ace54085d870dd45acae0f
Wraps the entire getDrawable() method in a try/catch block. Clears the
stack trace from the re-thrown exception, since we only need the trace
from the original exception.
Also clears stack traces from re-thrown RuntimeExceptions in applyTheme
implementations.
Change-Id: I92396abf9e748eef78777174b297a09e118f5e70
Refactors density handling to look more similar to GradientDrawable's
implementation, which should make things easier to maintain. We no
longer update density directly in updateStateFromTypedArray, instead
handling it in applyTheme() and inflate().
Lazily calculates local density-dependent dimensions and invalidates
when the constant state density changes, which should ensure a random
call to applyTheme() will still result in the correct intrinsic
dimensions.
Change-Id: I726878a6cd75d38a550637e3e7a7b6bc68bcaf6d
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
Refactors density resolution and offset/size scaling into static
helper methods.
Also fixes VectorDrawbale insets to be treated as offset-type pixels
rather than size-type.
Bug: 25081461
Change-Id: I10fcb9ebb6c67f853a27ca0ee008c31af4b85da0
Ensures that density scaling is applied to default dimension values
where needed. Previously, scaling was only applied when a drawable
was loaded from cached constant state; however, drawables that were
preloaded against a different density and first loaded in some other
density were not scaled.
Bug: 25081461
Change-Id: I0f8058cc01e2fe8d6bd7e255eba40485f3cbe48b
Only store stateful CSLs; otherwise, just use the default (e.g. the
only available) color.
Bug: 25074102
Change-Id: I050c89841d4c6bf22473a66c713a845b0358dc94
Removes unnecessary invalidateSelf() from VD.onStateChange(). This is
handled by the view hosting the drawable.
Bug: 22984152
Change-Id: Idf11a0ffef392cb1d8452aa3f5f836b35027a756
Cleans up collection typing and encapsulation. VObject encapsulates
inflation, theme application, and drawing. VFullPath is responsible
for rendering nodes to a Path.
Change-Id: Ic760576d8000c4844ec3cab1b4bbcecb4fa1b760
Before, the VectorDrawable is behaving like BitmapDrawable inside a ImageView,
and it can be blurry due to scaling.
Now apply the scaling information to the cached bitmap, then the size of bitmap
will match the ImageView's screen size. Therefore, no blurry any more.
b/18185626
Change-Id: I979cef3b5178a9bd37ee6cc776df3361ca47c803
Originally, stroke width is independent of group scaling.
But that is a bug and causing animation trouble.
b/19501782
Change-Id: I33d5e44f2f8b2a82fee1a5a326223a39aaffa86c
Ensures changing configurations mask is propagated to the host drawable
so that it can be properly cleared from cache on configuration changes.
Also fixes constant state handling of the mask in the Inset and Rotate
drawables.
Hides new ColorStateList methods related to theming, since they should
only be used during preloading or internally by framework drawables.
Fixes bug where the cached versions of themeable ColorStateLists were
modified by calling applyTheme() on the host drawable.
Also cleans up some docs and naming in GradientDrawable.
Bug: 19966397
Change-Id: I8c8d3cabbaf94b488c2b8fe9fd423e07d824c19c
