History log of /frameworks/base/libs/hwui/VectorDrawable.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
cc29a5dde1ef0a3cf0fcec10eb9d37d9e8fa3afb 15-Mar-2017 Stan Iliev <stani@google.com> Modify VectorDrawable to scale path through canvas matrix

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
89ddb1f1644e0b47de060d2c9aaf6d5387c38f2f 10-Feb-2017 Matt Sarett <msarett@google.com> Update framework to use new SkColorSpace API

Test: This compiles with SK_USE_LEGACY_NAMED_COLOR_SPACE
turned off.

Change-Id: Ie573f59e0aa475bab06b38589db3c6158ad82c5a
6e49c9f007c879f05b035c40c0ba543c00f9d0d0 02-Dec-2016 Mike Reed <reed@google.com> switch over clip calls to use SkClipOp instead of SkRegion::Op

Change-Id: I67d23c487b5249bc31d96e3b2393f693c0b2bcff
f2237741c3a0e6e6a0f814711bd42a7d071616f1 03-Dec-2016 Tenghui Zhu <ztenghui@google.com> Merge "Recreate the bitmap cache when it is smaller than needed"
037fc1815b0f69b0b24e68e16281b490bdeb1d56 16-Nov-2016 Teng-Hui Zhu <ztenghui@google.com> Recreate the bitmap cache when it is smaller than needed


Test: Existing CTS and attached repro apk.

Change-Id: Ib908319af6539b2438b850f7a50d5a539cef8368
ab12c1fe73734a18ac19a06b97f276528f6d027a 03-Nov-2016 Mike Reed <reed@google.com> update callers to newer Skia APIs

Test: refactoring CL. Existing unit tests still pass.

Change-Id: I47e73e00f14f78dd9d4c48a142ac9853e7e4cad7
fc9999505a36c66892d7ccce85187936105f4f36 17-Oct-2016 sergeyv <sergeyv@google.com> Pass Bitmap instead of SkBitmap for bitmap rect operation
Test: refactoring cl.

Change-Id: I66d19194c57b3aa2c400aa87acffc774a533776a
260ab726486317496bc12a57d599ea96dcde3284 07-Oct-2016 Mike Reed <reed@google.com> use SkBlendMode instead of SkXfermode
use sk_sp versions of paint setters/getters

Change-Id: I86591a0a8ec92e6039776cbf00424ea24f585b28
4e230f4688e85551252dfaf94cbaab3c9087ab3b 12-Oct-2016 Doris Liu <tianliu@google.com> Fix SkShader leak for Gradient VectorDrawable and test am: fc9cf72339 am: c47199bb6a
am: 1ef744a3b8

Change-Id: Iee4f98f10a4e1b3947166777040918ab779ab023
fc9cf72339c7ce61adb11ceb3b247f112577fb6b 11-Oct-2016 Doris Liu <tianliu@google.com> Fix SkShader leak for Gradient VectorDrawable and test

This CL fixes a SkShader leak in VD when applying local matrix
to the shader. Specifically, the usage of newWithLocalMatrix(...)
increments the shader's ref count in every draw() call for
Gradient VectorDrawable, whereas there's no balancing call to
decrement the ref count in draw(). In this CL, we assume
the ownership of the shader returned from newWithLocalMatrix(...)
to ensure the correct ref count management.

Also, add test to verify that shader is no longer being leaked

BUG: 32067647
Test: this CL

Change-Id: Ic15fe46cde06a73d81b44e2d3c56b51907344cc0
253f2c213f6ecda63b6872aee77bd30d5ec07c82 29-Sep-2016 Romain Guy <romainguy@google.com> Linear blending, step 1

NOTE: Linear blending is currently disabled in this CL as the
feature is still a work in progress

Android currently performs all blending (any kind of linear math
on colors really) on gamma-encoded colors. Since Android assumes
that the default color space is sRGB, all bitmaps and colors
are encoded with the sRGB Opto-Electronic Conversion Function
(OECF, which can be approximated with a power function). Since
the power curve is not linear, our linear math is incorrect.
The result is that we generate colors that tend to be too dark;
this affects blending but also anti-aliasing, gradients, blurs,

The solution is to convert gamma-encoded colors back to linear
space before doing any math on them, using the sRGB Electo-Optical
Conversion Function (EOCF). This is achieved in different
ways in different parts of the pipeline:

- Using hardware conversions when sampling from OpenGL textures
or writing into OpenGL frame buffers
- Using software conversion functions, to translate app-supplied
colors to and from sRGB
- Using Skia's color spaces

Any type of processing on colors must roughly ollow these steps:

[sRGB input]->EOCF->[linear data]->[processing]->OECF->[sRGB output]

For the sRGB color space, the conversion functions are defined as

OECF(linear) :=
linear <= 0.0031308 ? linear * 12.92 : (pow(linear, 1/2.4) * 1.055) - 0.055

EOCF(srgb) :=
srgb <= 0.04045 ? srgb / 12.92 : pow((srgb + 0.055) / 1.055, 2.4)

The EOCF is simply the reciprocal of the OECF.
While it is highly recommended to use the exact sRGB conversion
functions everywhere possible, it is sometimes useful or beneficial
to rely on approximations:

- pow(x,2.2) and pow(x,1/2.2)
- x^2 and sqrt(x)

The latter is particularly useful in fragment shaders (for instance
to apply dithering in sRGB space), especially if the sqrt() can be
replaced with an inversesqrt().

Here is a fairly exhaustive list of modifications implemented
in this CL:

- Set TARGET_ENABLE_LINEAR_BLENDING := false in BoardConfig.mk
to disable linear blending. This is only for GLES 2.0 GPUs
with no hardware sRGB support. This flag is currently assumed
to be false (see note above)
- sRGB writes are disabled when entering a functor (WebView).
This will need to be fixed at some point
- Skia bitmaps are created with the sRGB color space
- Bitmaps using a 565 config are expanded to 888
- Linear blending is disabled when entering a functor
- External textures are not properly sampled (see below)
- Gradients are interpolated in linear space
- Texture-based dithering was replaced with analytical dithering
- Dithering is done in the quantization color space, which is
why we must do EOCF(OECF(color)+dither)
- Text is now gamma corrected differently depending on the luminance
of the source pixel. The asumption is that a bright pixel will be
blended on a dark background and the other way around. The source
alpha is gamma corrected to thicken dark on bright and thin
bright on dark to match the intended design of fonts. This also
matches the behavior of popular design/drawing applications
- Removed the asset atlas. It did not contain anything useful and
could not be sampled in sRGB without a yet-to-be-defined GL
- The last column of color matrices is converted to linear space
because its value are added to linear colors

Missing features:
- Resource qualifier?
- Regeneration of goldeng images for automated tests
- Handle alpha8/grey8 properly
- Disable sRGB write for layers with external textures

Test: Manual testing while work in progress
Bug: 29940137

Change-Id: I6a07b15ab49b554377cd33a36b6d9971a15e9a0b
028029730bf2d177f84316d2d444d409eba4b6cb 27-May-2016 Doris Liu <tianliu@google.com> Copy native tree's property when mutate vector drawable

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
335d7d174464ea3fc2d058dcff6e436df1cf0fd9 27-May-2016 Doris Liu <tianliu@google.com> Copy native tree's property when mutate vector drawable

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
f8d131cc8dc4ef675b8f8fc57dcc26062d575d32 30-Apr-2016 Doris Liu <tianliu@google.com> Count native allocation for VD against Java heap

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
b35da390601e3c24e777d72daacd8dbeb4d1d9c4 12-Apr-2016 Doris Liu <tianliu@google.com> Allow leading spaces in path string (to keep behavior consistent)

Bug: 28132454
Change-Id: Iee799c13a85738db3d6940aca0fe917f284fa651
1d8e194661085f9a18ab1b3cd12f9e19d3a86be5 03-Mar-2016 Doris Liu <tianliu@google.com> Make AVD thread safe

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
71e806b2f464b0ac85367fe008b554b44e4c5812 16-Mar-2016 Tenghui Zhu <ztenghui@google.com> Merge "Add fillType support to VectorDrawable" into nyc-dev
46591f4a2dbd785bcae2b82bb490e78208605ec8 15-Mar-2016 Teng-Hui Zhu <ztenghui@google.com> Add fillType support to VectorDrawable

Default as non-zero, which is the same as SVG.

Change-Id: Id20e6d3493bb4d2b4b65d7f6cdb13586631c40e4
24ba1251583dc637ff1699550aa99811e886b4cf 16-Mar-2016 Doris Liu <tianliu@google.com> Workaround for PathMeasure.getSegment() behavior change

SkPathMeasure::getSegment(SkScalar startD, SkScalar stopD, SkPath* dst,
bool startWithMoveTo) in SkPathMeasure used to ignore the case when
startD == stopD in MNC release. In NYC, the same paramaters would yield
a tiny segment, which leaves undesirable artifacts as shown in the bug

Bug: 27665826
Change-Id: I8289dc32773fd55d686458183af44ff072866c6e
ef062ebd20032efe697741d6c3dfd1faec54f590 05-Feb-2016 Doris Liu <tianliu@google.com> Ref count the nodes in VectorDrawable

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
766431aa57c16ece8842287a92b2e7208e3b8ac3 04-Feb-2016 Doris Liu <tianliu@google.com> Revert "Revert "VectorDrawable native rendering - Step 4 of MANY""

This reverts commit 5a11e8d0ba21624025b89ac63bbd18befa55be0e.

Change-Id: I7a48b59c4f930dad65ddc8590c25a12636244ea2
5a11e8d0ba21624025b89ac63bbd18befa55be0e 04-Feb-2016 Doris Liu <tianliu@google.com> Revert "VectorDrawable native rendering - Step 4 of MANY"

b/26949340 and b/26975469, b/26975079 as well

This reverts commit f276acd98457bcaabc9e79a17a736b3b484f005e.

Change-Id: I4b55177daf0d289bc03604c71fd4bf579f65073a
777bf85c1631acdc81d88d841266e585caed7e15 03-Feb-2016 Florin Malita <fmalita@google.com> Remove remaining references to SkCanvas::SaveFlags

One SkCanvas save flag reference snuck back in after the last
cleanup. Convert to the new SaveFlags enum.

Change-Id: I9ba4b01a19bbb80276c84d30fd0d7b9513892cf9
f276acd98457bcaabc9e79a17a736b3b484f005e 07-Jan-2016 Doris Liu <tianliu@google.com> VectorDrawable native rendering - Step 4 of MANY

This CL runs VectorDrawable animation on RenderThread. The changes in this CL
- 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.

- Implement reverse and reset for AVD.

Change-Id: I2df1d754f2db0ad098d9c15dde4bb2bdfafc2315
28d4ea558435b1b245bd5774c0db056a2ffdb385 28-Jan-2016 Teng-Hui Zhu <ztenghui@google.com> Fix redundant drawPath call

Change-Id: I17dab39e0ca60f64543053381d8677f1a31507c0
dbee9bb342cdfaa5155b1918f90262c05e2464cb 15-Dec-2015 Teng-Hui Zhu <ztenghui@google.com> Gradient for VectorDrawable's fill and stroke

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.


Change-Id: Ibdc564ddb4a7ee0133c6141c4784782f0c93ce0e
eecff56fed5dd5206acfbc5007b4912081b36d3b 21-Dec-2015 Florin Malita <fmalita@google.com> Add internal Canvas save flags

Skia's SkCanvas::SaveFlags are being deprecated. This CL introduces
the equivalent android::SaveFlags, converts all internal clients to
the new enum, and switches the saveLayer glue to the
SaveLayerRec-based API.

Change-Id: Icb1785f4e7c0f652b1f04b34a1e3ccb063c408f3
c2de46fadd4ca9c6aa2d9dd7a65b161b28fc6f3b 21-Jan-2016 Doris Liu <tianliu@google.com> Create SkCanvas on the stack to avoid leaking memeory

Bug: 26447978
Change-Id: Ied022c103c3b08e9cfc3cb775a8c95fd5461e81d
e410a357f50651065a0cb39d8de809c861b56f75 14-Jan-2016 Doris Liu <tianliu@google.com> Properly handle the negative scaling factor of canvas in VectorDrawable

Bug: 26489687
Change-Id: I91cce34759fbbac206cd59f4636fd92194396c87
a0e61572ab2ec23f1329a04f6a8065721a1efbdb 29-Dec-2015 Doris Liu <tianliu@google.com> VectorDrawable: Use the matrix scale only if the matrix has no rotation or skew.

When canvas is rotated or skewed, the scale factor is affected.
Conservatively reset the scale used to modify path stroke size to 1 in these
cases, since the image will be somewhat blurry anyway with rotation / skew..


Change-Id: I6dff1bca5fac5500fa688c68f8b81b6212526b6b
4bbc2931263b232fba61807fca00e127573eff42 02-Dec-2015 Doris Liu <tianliu@google.com> VectorDrawable native rendering - Step 3 of MANY

- 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