Update pointer to SkRefCnt fields which require it to sk_sp.
Test: refactoring CL. Existing unit tests still pass.
Change-Id: I4f3eb790ee67c09746708458c4492569b64cc58f
This removes the duality of DisplayList, removing a small amount of
overhead
Test: buids & hwuiunit passes
Change-Id: I8bb3a20e9ead1caec4b4a8a3e9f2c08f717a7096
Cache VectorDrawable bounds at record time, because the same
drawable object may be used several times with different bounds.
Bug: 71737362
Test: Wrote a new unit test, tried sample app attached to the bug
Change-Id: If7be934acf0c16b328cb0f95d849e463dcd3b88b
Bug: 69322344
Test: visual inspection on VectorDrawableTest with AA off. Jagged edges
that are otherwise smooth were spotted.
Change-Id: Ib2dfbd3a941be0b4ff92b8458346f8c8f5015a4b
Pass VD staging dirty flag value to the render thread dirty flag.
This is fixing animation on growing VD bounds, which looked bad
because cache was not refreshed and scaling it up 100 times did
not look good.
Test: Ran GoogleCamera app and HWUI unit tests.
Bug: 65534766
Change-Id: Ie83cbb6839c772556340b4ec526ba3699fc84255
For frames with multiple VDs the context switching involved was causing
worst case frame times of ~40ms to draw all VDs in the frame whereas
this new approach has worst case performance of ~5ms when drawing the
same frame (w/ approximately 26 VDs).
Bug: 64487466
Test: SystemUiJankTests#testGoToFullShade
Change-Id: I5cad0b5df86e5eac3722ee8695fc7511b38b8a7c
Optimize VectorDrawables for Skia pipeline: draw small VectorDrawables
in a GPU atlas instead of seprate offscreen buffers.
This implementation is using CacheManger and allows for the atlas to
be released if there is a memory pressure.
Test: A new unit test for VectorDrawableAtlas is passing. Systrace shows
0.5ms faster DrawFrame for fling in Settings app main screen.
Change-Id: Ide3884eefae777e1547f1dfdb67b807185839fb4
Draw VectorDrawables in GPU backed surface. Render VD cache
at the beginning of the frame to avoid context switching.
Test: CTS graphics tests pass.
Change-Id: Ia14e0ec4049c3fa87f03547fbda44043bf8dd793
Apply the path matrix to the canvas instead of creating a new path.
Delete logic that scales the stroke, because this is done through
the matrix as well. Merge/delete some functions.
Bug: 36392701
Test: CTS graphics tests pass with minor changes in 6 golden images.
Quick settings and settings app drawables are OK. Vector icon app
draws identical paths.
Change-Id: If623bc0a535fad95a2839f79bd997c016bcd9d4d
VectorDrawable contains properties that can be mofidied from both
UI thread and RenderThread. The two sets of properties are synced
during prepareTree. Previously VD animations ran before prepareTree,
as a result, during prepareTree the property sync overwrote some
of the animatable properties. In other words, the first frame of
the animation wasn't correct. An example is in battery saver mode
when the animation only has one frame to animate (0-duration), the
end result looked wrong.
This CL moves the VD animation to after prepareTree to solve the
problem mentioned above. Meanwhile, in order to signal which
VD will be animated so as to have them properly damaged, all VDs
with running animators are marked dirty.
Bug: 30226711
Change-Id: I831dae9abb2908876c935b9be4c11dfd09452d5c
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
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: If793f5f2b6e116472a1c6da0fb60d8278a78b03f
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: Id4b3b37f28274c917cb9beb9dcd3d1e6991b5c5d
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
Originally the logs are added to track potential performance bug.
Like unexpectedly deep recursion loop.
However so far, we haven't captured anything by these logs.
And they are causing some misunderstanding in some bugs.
So I think it is better to disable it by default.
In the future, we will consider switching to direct Skia arcTo support
and drop this part.
Change-Id: Iff6df7a92e40b4775a644a1497e113de0eedbc8a
This CL introduces staging properties to VectorDrawable, which holds
properties coming from UI thread. When staging properties are changed,
they are marked dirty, and the staging properties then get pushed to
RenderThread at sync point. In cases where no staging property has
been changed, at sync point we sync the render thread properties back
to staging properties to reflect the latest render thread animation
value change.
Also, update Vector Drawable bitmap only when it's dirty
Bug: 27343970
Bug: 27385912
Bug: 27263667
Bug: 27927674
Bug: 27774383
Change-Id: Ia864f5400a53a08dbfb284fae581fb1aac4fff87
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
