First, this CL removes the need to decompose the DrawFilters
in Java and instead passes the SkDrawFilter to HWUI directly.
This also allows the removal of duplicated logic between HWUI
and other Canvas implementations regarding Paint filter levels.
Second, the DrawFilter is now stored in the DisplayListRenderer
where we apply it to every paint BEFORE it is stored in the
DisplayList. This eliminates the need to filter all Paints on
playback and removes additional complexity at playback.
Finally, as a result of storing the filtered paint we can now
do a better job caching the paints. This takes advantage of
recent changes in Skia to quickly enable quick hashing and
comparison of paint objects.
Change-Id: Iec507a2d894827975cc4f1d22241542bb0534b4e
Narrow the use of #include directives in hwui, replacing with forward
declarations where straightforward. Speeds compiles; doesn't do any
restructuring of code.
Change-Id: Icac2baffb5896f55d8c6718e9bd9d4bfa02d3ca0
Bug: 16712006
Initial work towards benchmarking HWUI systems
Currently this will just create a screen full of
"cards" to simulate a high load scenario for
shadows and clipping
Change-Id: Ie9f9a9570844e136db8053e8fc62fe06cb922a5f
Graphics memory usually gets trimmed in applications when the
activity goes into the background. We use quite a lot of graphics
memory when the shade/lockscreen is open, and some of them never gets
freed unless the recents activity is closed, because we don't have
these activity-trimming-heuristics for the shade. This change
proactively trims the graphics memory when the shade gets closed or
when the lockscreen is hidden, to emulate the same heuristics as for
activities.
This change also adds trimMemory on RenderThread to systrace to
verify that no jank is introduced with this change.
This change immediately saves around 10-30 MB on an xxhdpi device
after the shade is closed.
Bug: 17581375
Change-Id: I4fb622efb51815fe08187be97ba15d012d4de5d4
This is helping spot shadow for 15%-20% increase.
With the new algorithm, we are less sensitive to the floating point error.
b/16712006
Change-Id: Ie30a6ce01e73d56054a0cf65a84549454339a7fd
Bug: 17765082
DeferredLayerUpdater had fallen behind RT updates. Re-snap to
latest expectations, ensuring to call requireGlContext() prior
to detachSurfaceTexture to avoid leaking SurfaceTextures
Change-Id: Ic65fb9831e5284f658866da8da9ad5af1d227699
+ adjusting spot and ambient shadow opacity constants to achieve desired appearance
+ reducing ambient scale ratio back to 1.0 to address over-lightening at higher elevations
+ partially revert ag/546290
Change-Id: I9d7f664f73a7b9b83df73b739103c97054bd4f6e
In our devices with higher resolution we have observed a memory
leak in the HWUI code. When there is GC or tree modification
and buffer size is greater than the default size, we make sure
buffer is deleted.
Change-Id: Idf7052ccaf43c8a784ce0e7bdab336dca29bffd8
Signed-off-by: Samsung <aosp@samsung.com>
bug:17600162
Transparent draws are not safe to reject for all xfermodes other than
clear. Now, to be safe, only perform the rejection for SrcOver draws
since other modes are fairly uncommon.
We could specifically determine whether the xfermode could change the
output given a transparent input, but there's little to be gained from
the additional complexity.
Change-Id: Ia699ac4bdc4da3353955840b53f1922d3cb1d85d
