| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
Test: make
There is no longer any intent to turn on linear blending.
Change-Id: Ia1016f31833212da6ad4b4c6ebe03d16a509746d
|
|
Test: No code changes, just ran through clang-format
Change-Id: Id23aa4ec7eebc0446fe3a30260f33e7fd455bb8c
|
|
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
|
|
Release VectorDrawable cache surface on render thread.
This is fixing an assert in skia GrSingleOwner.h:33.
Test: Ran gmail before and after the change.
Bug: 64842607
Change-Id: I46e0c2557ac5b2fc3be2cc2d35abf96f6d6c9399
|
|
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
|
