| Age | Commit message (Collapse) | Author |
|---|
|
Test: It makes
Bug: 183120308
Change-Id: I331262dd2da59817031f0c708f4c102041dcb5e0
|
|
1. drawBitmap --> drawImage
2. drawImage now always requires sampling parameter
Bug:178700363
Test: make
Change-Id: I96f610a180b3774ba955cc334949fd62b1cf4d69
|
|
Drawing a mutable SkBitmap to an SkCanvas will result in the pixels
being copied and a new genID assigned. This results in both a cpu
and gpu copy every time a VectorDrawable is redrawn.
The solution is to create an SkImage using the flag to instruct it
not to copy the pixels which is what Bitmap::makeImage() does.
Bug: 173732636
Test: captured SKP and verified the genID is consistent between frames
Change-Id: Ie13385e89de51c6b9ee2f2ba31eccbfdf3adac48
|
|
This reverts commit fc42a99ea5712883c9872d34a523d972c26c9d6f.
Because we are moving away from a wrapper class to delegate
between SkImageFilter and SkShader and instead adding
RenderEffect on RenderNode, this wrapper implementation
is no longer necessary. There are some behavioral
differences between SkShader and SkImageFilter that
would lead to additional complexity in conversions
between these objects and potential bugs.
To simplify this, RenderEffect will be added
directly to RenderNode to support better
caching of rasterization layers that is necessary
for various visual effects like blur.
Test: N/A
Change-Id: I65dc9f8bd26aed8761af13491ae3f6d583208377
|
|
Created Shader classes to wrap existing shader classes
in the framework in order to handle creation of either an
SkShader or SkImageFilter.
Updated native Paint implementation to optionally configure
the currently configured SkShader or SkImageFilter
Bug: 143468037
Test: re-ran CtsGraphicsTestCases and CtsUiRenderingTestCases
Change-Id: I7663b92766c912ab3866cf4e39b268f6dcf5d8e2
|
|
Test: make
Change-Id: I8f20b7da284483ea4f59e35d9c3d48202cba02d5
|
|
Poking around in a few apps it doesn't appear that
the VectorDrawableAtlas is achieving sufficient
utilization to justify its existence. The potential for
draw call merging doesn't seem warranted for the
RAM cost of the atlas.
Bug: 137853925
Test: builds
Change-Id: Id2419bc6dccb6316636d50c568f8fac75a2d563f
|
|
VectorDrawableAtlas dtor can run only on RenderThread, because
it releases GPU resources. It is usually CacheManager, which
destroys the atlas on RenderThread in response to trimMemory.
This CL fixes a rare situation, when a Java finalizer thread
deletes the atlas.
Bug: 137722646
Test: Manual testing on a device
Change-Id: I9d900809c23efaead9aaf16ee3306bc8c7c6b379
|
|
Test: cts
Change-Id: I9a3314bc3f221b6e884c8c84d7b0241f7c5be600
|
|
The purpose of this is to be able to use the native graphics code from
the Android platform directly in Android Studio (running on desktop) to
do layout rendering.
This creates a host library that is a subset of libandroid_runtime
including only the JNI files relevant to Android graphics. It also
includes LayoutlibLoader.cpp which is used to load the JNI when using
it as part of layoutlib (the graphics library for Android Studio).
This also creates libhwui-host, a host library that is a subset of
libhwui.
Bug: 117921091
Test: lunch sdk && m libandroid_runtime
Change-Id: I3850020d2d4c13c85e377476bc463d3eb6a01c6d
|
|
Bug: 128805564
Test: Manual + systrace; hwui_unit_tests; CtsUiRenderingTestCases
Only update a VectorDrawable's cache if it is onscreen. This fixes a
Twitter use case where the app has a ProgressBar that is exactly one
pixel offscreen. Prior to this CL, we repeatedly drew the ProgressBar's
AVD to a GPU surface, even though we clip it out later and never draw
that GPU surface. Now, we recognize that the AVD is outside of the
bounds of the screen, so we never draw to the GPU surface.
TreeInfo:
- store the size of the screen, retrieved from
CanvasContext::getNextFrameSize.
SkiaDisplayList:
- Store the matrix at the time of recording a VectorDrawable. Concat
that with the current matrix to determine whether the VD is on screen,
based on the TreeInfo. If it is offscreen, do not add it to the list
of AVDs that need to be updated ahead of rendering.
- In addition, if it is offscreen (or not dirty), do not call
setPropertyChangeWillBeConsumed(true). This prevents triggering
dispatchFrameCallbacks to update on the RenderThread when there is no
need to. This also mimics what would happen if the View/RenderNode had
been completely offscreen.
- Add a method to append an AVD to mVectorDrawables. Now that the vector
is of Pairs, this simplifies the call sites. Add a second helper to
just add an AVD without a matrix, for use in tests.
SkiaRecordingCanvas:
- get the current matrix and store it in the display list along with the
AVD.
CanvasContext:
- add getNextFrameSize, for reporting the size of the next frame without
dequeuing it
VectorDrawable.cpp:
- call quickReject to potentially short circuit drawing. This is for a
hypothetical use case (verified in a test app) where the containing
RenderNode is partially onscreen, but the AVD itself is not. Even
without the change to VectorDrawable.cpp, we skip uploading to the GPU
cache, the SkiaDisplayList still attempts to draw it. This change
keeps us from drawing it at all.
SkiaDisplayListTests.cpp:
- Now that I've hidden mVectorDrawables, call the new public APIs.
- prepareListAndChildren test
- for the clean VD, assert that getPropertyChangeWillBeConsumed
returns FALSE. This is due to the behavior change that we do not
set it unless the VD is dirty.
- set the bounds, so our onscreen check works.
- Add another test for prepareListAndChildren, which puts VDs offscreen.
Change-Id: Iae0a07adcf58e7884e0854720de644e7b2faf2bf
|
|
Test: make
There is no longer any intent to turn on linear blending.
Change-Id: Ia1016f31833212da6ad4b4c6ebe03d16a509746d
|
|
Bug: 122856066
Test: PictureCaptureDemo
Change-Id: Iaf3a4bc1c8a2c18c7dff635c5f1cf726b331f8bf
|
|
When closing a namespace a } is sufficient. It doesn't need to be };
like closing a class or enum.
Within frameworks/base/libs/hwui there is a mix between } and }; when
closing a namespace. There are even mixes between a .h and the
corresponding .cpp files.
In a separate CL I was asked to not close with };. That was a good
comment. I adopted the style from nearby code. This CL cleans up the
nearby code.
Test: I made sure the code still built as expected.
Change-Id: Ieb314a4f48d6e33752463f3be4361fdc9be97482
|
|
BUG: 116355161
Test: cts-tradefed run commandAndExit cts -d --skip-preconditions --test android.graphics.drawable.cts.VectorDrawableTest --module CtsGraphicsTestCases
Change-Id: I4d1bc13d8544d0fc64c5457f8a70c3089a9334c1
|
|
Also fixes a bug where non-animatable properties (colorfilter)
weren't captured at record-time
Test: poked around, quick settings doesn't look awful
Change-Id: I57312dd5eb70f477814a4d898963ee010153c243
|
|
Set filter quality to GL_LINEAR, when drawing
VectorDrawable cache into the frame buffer.
Bug: 77841258
Test: Search bar icon jagged edge in launcher fixed
Change-Id: I91270f64964ae3ba7a47264aec395bc2c2d9e968
|
|
Move all HW bitmap upload operations off of RenderThread.
Ensure EGL context outlives all upload requests
Bug: 79250950
Test: builds, boots, systrace is good, CTS bitmap tests pass
Change-Id: I5ace6c516d33b1afdf1a407cd8b183f6b60c22c1
|
|
Test: make
Change-Id: I6af16bf4a8c9952d2e493cbd34b6db58d581a694
|
|
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
|
|
Test: No code changes, just ran through clang-format
Change-Id: Id23aa4ec7eebc0446fe3a30260f33e7fd455bb8c
|
|
We didn't trace the draw from cache.
Here we add trace for draw into bitmap, which is normally heavy.
fix: 65060698
Test: run test app and get systrace and check
Change-Id: Ia81127c4aa285b3277e9c9edbdf356d85cb28b5e
|
|
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
|
|
Bug: 64487466
Test: CtsGraphicsTestCases, CtsUiRenderingTestCases
Change-Id: Ib2312598b50d402b1749d62a10c6ec343eff5b89
|
|
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
|
|
Test: This compiles with SK_USE_LEGACY_NAMED_COLOR_SPACE
turned off.
Change-Id: Ie573f59e0aa475bab06b38589db3c6158ad82c5a
|
|
Change-Id: I67d23c487b5249bc31d96e3b2393f693c0b2bcff
|
|
|
|
fix:32780212
Test: Existing CTS and attached repro apk.
Change-Id: Ib908319af6539b2438b850f7a50d5a539cef8368
|
|
Test: refactoring CL. Existing unit tests still pass.
Change-Id: I47e73e00f14f78dd9d4c48a142ac9853e7e4cad7
|
|
Test: refactoring cl.
bug:32216791
Change-Id: I66d19194c57b3aa2c400aa87acffc774a533776a
|
|
use sk_sp versions of paint setters/getters
Change-Id: I86591a0a8ec92e6039776cbf00424ea24f585b28
|
|
c47199bb6a
am: 1ef744a3b8
Change-Id: Iee4f98f10a4e1b3947166777040918ab779ab023
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Bug: 28132454
Change-Id: Iee799c13a85738db3d6940aca0fe917f284fa651
|
|
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
|
|
|
|
Default as non-zero, which is the same as SVG.
b/27533958
Change-Id: Id20e6d3493bb4d2b4b65d7f6cdb13586631c40e4
|
|
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
|
|
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 reverts commit 5a11e8d0ba21624025b89ac63bbd18befa55be0e.
Change-Id: I7a48b59c4f930dad65ddc8590c25a12636244ea2
|
|
b/26949340 and b/26975469, b/26975079 as well
This reverts commit f276acd98457bcaabc9e79a17a736b3b484f005e.
Change-Id: I4b55177daf0d289bc03604c71fd4bf579f65073a
|
|
One SkCanvas save flag reference snuck back in after the last
cleanup. Convert to the new SaveFlags enum.
Change-Id: I9ba4b01a19bbb80276c84d30fd0d7b9513892cf9
|
