| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 6e49c9f007c879f05b035c40c0ba543c00f9d0d0 |
|
02-Dec-2016 |
Mike Reed <reed@google.com> |
switch over clip calls to use SkClipOp instead of SkRegion::Op
Change-Id: I67d23c487b5249bc31d96e3b2393f693c0b2bcff
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
fix:32780212
Test: Existing CTS and attached repro apk.
Change-Id: Ib908319af6539b2438b850f7a50d5a539cef8368
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| fc9999505a36c66892d7ccce85187936105f4f36 |
|
17-Oct-2016 |
sergeyv <sergeyv@google.com> |
Pass Bitmap instead of SkBitmap for bitmap rect operation
Test: refactoring cl.
bug:32216791
Change-Id: I66d19194c57b3aa2c400aa87acffc774a533776a
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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,
etc.
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
follows:
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
extension
- 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| b35da390601e3c24e777d72daacd8dbeb4d1d9c4 |
|
12-Apr-2016 |
Doris Liu <tianliu@google.com> |
Allow leading spaces in path string (to keep behavior consistent)
Bug: 28132454
Change-Id: Iee799c13a85738db3d6940aca0fe917f284fa651
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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.
b/27533958
Change-Id: Id20e6d3493bb4d2b4b65d7f6cdb13586631c40e4
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
below.
Bug: 27665826
Change-Id: I8289dc32773fd55d686458183af44ff072866c6e
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 28d4ea558435b1b245bd5774c0db056a2ffdb385 |
|
28-Jan-2016 |
Teng-Hui Zhu <ztenghui@google.com> |
Fix redundant drawPath call
Change-Id: I17dab39e0ca60f64543053381d8677f1a31507c0
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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.
b/22564318
Change-Id: Ibdc564ddb4a7ee0133c6141c4784782f0c93ce0e
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| c2de46fadd4ca9c6aa2d9dd7a65b161b28fc6f3b |
|
21-Jan-2016 |
Doris Liu <tianliu@google.com> |
Create SkCanvas on the stack to avoid leaking memeory
Bug: 26447978
Change-Id: Ied022c103c3b08e9cfc3cb775a8c95fd5461e81d
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| e410a357f50651065a0cb39d8de809c861b56f75 |
|
14-Jan-2016 |
Doris Liu <tianliu@google.com> |
Properly handle the negative scaling factor of canvas in VectorDrawable
Bug: 26489687
Change-Id: I91cce34759fbbac206cd59f4636fd92194396c87
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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..
b/25418943
Change-Id: I6dff1bca5fac5500fa688c68f8b81b6212526b6b
/frameworks/base/libs/hwui/VectorDrawable.cpp
|
| 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
/frameworks/base/libs/hwui/VectorDrawable.cpp
|