History log of /frameworks/base/libs/hwui/ResourceCache.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
5a4690bf26932c0d6940e4af8516d920e09ae81a 14-Jul-2015 Chris Craik <ccraik@google.com> Clean up unncessary defines

LOG_TAG and TRACE_TAG are already defined in the makefile

Change-Id: I9e53e3dacbe018441edd74cb7c8c90846defee74
e75ab4c26a4f661334845f7bc4132011694836a4 07-May-2015 John Reck <jreck@google.com> Remove SkBitmap from ResourceCache

Bug: 18928352

Fully-proper refcounting via SkBitmap/SkPixelRef, no more
side-channel refcounting via ResourceCache. Makes HWUI
more resilient to the bitmap being modified as well as
the SkBitmap's info & rowBytes() is updated every time
a DisplayList is recorded instead of relying on buggy
cache eviction logic

Change-Id: I2e8292d62ab6c257a2cfa1542387bf2bf1ade816
7c103a36f60b690e3fe83c40210e1cb0c76bba43 16-Apr-2015 John Reck <jreck@google.com> Remove Bitmap#getSkBitmap

Change-Id: Ifb9047b426122d3e5a445eb7a0eb3fce38dedf27
1ff961dd6d51247e82e41de052f04fd0b577f09b 17-Apr-2015 John Reck <jreck@google.com> Revert "Remove Bitmap#getSkBitmap"

This reverts commit 4bd981ec533a65e8dee053a0a709b484770b0a76.

Change-Id: I5c92cd955c6e70e197dc5cbc5dfeed8369a24a31
4bd981ec533a65e8dee053a0a709b484770b0a76 16-Apr-2015 John Reck <jreck@google.com> Remove Bitmap#getSkBitmap

Change-Id: Ifb9047b426122d3e5a445eb7a0eb3fce38dedf27
ee248599d49a15fc207c5aeb0b90ec263cc1d600 12-Feb-2015 Derek Sollenberger <djsollen@google.com> Refactor DisplayList path caching.

This removes dependence on SkPath ptrs that HWUI does not control
the lifecycle of. This clears up some errors where the paths are
not generated from Java, but rather the Skia test suites.

Cherry-pick of a change that originally landed in master-skia and is
dependent on a skia merge (ag/655422).

Change-Id: I41b9797a2b0af5d6b4ea51891565469d4f1d832d
3d4eed7f1aa99401dabe2e45b82f98fb4fc2d754 04-Dec-2014 Derek Sollenberger <djsollen@google.com> Update HWUI to store its own SkBitmap objects

This enables us to...

1) simplify the lifecycle/ownership between Java and HWUI
2) remove DisplayListRenderer::drawBitmapData and associated logic
3) track pixel lifecycle using standard SkPixelRef refcounting
4) Remove uncessary calls to ref/unref the bitmap's pixels and colorTable

Change-Id: I3c95078da20995444f6388a029414280fd654318
d41c4d8c732095ae99c955b6b82f7306633004b1 06-Jan-2015 Chris Craik <ccraik@google.com> Add overrides and switch to nullptr keyword for all files

Adds remaining missing overrides and nullptr usages, missed due to
an extreme failure in tool usage.

Change-Id: I56abd72975a3999ad13330003c348db40f59aebf
a2732a2bf98f7dbd063f4e5679f5b8bfcbec2698 18-Dec-2014 John Reck <jreck@google.com> Stop pretending USE_OPENGL_RENDERER is a thing

Change-Id: I732b490431fe90eafa00a00f3b5429f0d3a067e6
ee648e517f09cccf59010a7423240a38aaeb2c04 09-Dec-2014 Derek Sollenberger <djsollen@google.com> Remove unnecessary/erroneous reference counting

The SkBitmap* used by HWUI holds a reference to the PixelRef (which
in turn holds the colorTable) so keeping an additional ref is not
only unnecessary, but also potentially problematic.

If a bitmap changes its pixelRef after it has been added to a displayList,
then we end up with unbalanced ref/unref calls that cause the newly added
PixelRef to be unref'd and prematurely deleted, while the original PixelRef
is leaked.

bug: 18659976
Change-Id: I34a06152e7bb2d733249a207dafd36b9b5dc0712
71d08a07189c2b433080203895d9d5e936b16b9e 25-Nov-2014 John Reck <jreck@google.com> Switch TextureCache to SkPixelRef::fStableId

Bug: 18245805
Change-Id: I08e6792dbeed86b13e569c7f2137de0e50dc2763
a35778c799e8073a42b9e22191bde9d838327ab7 06-Nov-2014 John Reck <jreck@google.com> Yank ResourceCache out of Caches

Bug: 17947547

Pull the ResourceCache (aka, ref-counting side channel) out of
Caches so that DisplayListRenderer doesn't use Caches, avoiding
the risk of instantiating Caches on the wrong thread or
without a GL context

Change-Id: I7d63b70b3b0a0163308c5dedd6ef255eadebe8fd
0e89e2b7bcb2c035e8cee77f93120e7c5617f8d2 31-Oct-2014 John Reck <jreck@google.com> Layer changes

Bug: 17208461

* Switch Layer to be VirtualLightRefBase instead of
Caches' side-channel ref-counting
* Include active layers in gfxinfo dump
* Run gfxinfo dump on the correct thread
* Dump gfxinfo on Layer creation failure

Change-Id: I28d195699e2334518e215ab28c7a17355aee9678
d1ad5e62fda248c6d185cde3cb6d9f01a223066c 05-May-2014 Leon Scroggins III <scroggo@google.com> Inspect SkShader to determine hw shader.

Instead of duplicating internal info about SkShader, inspect the
SkShader installed on the SkPaint.

Remove setupModifiers, nResetModifiers, and nSetupShader.

Remove calls to create/destroy the (previously) attached SkiaShader.

Remove native code for setupShader and resetModifiers.

Remove code keeping track of native SkiaShader.

Include Extensions.h.

Compare shaders on the paint, instead of on DrawModifiers.

Remove vector of SkiaShaders.

Access the SkShader on mPaint.
Remove SetupShaderOp and ResetShaderOp.

Remove resetShader, setupShader, refShader, and mShaderMap.

Pass SkShader to setupDrawShader and setupDrawShaderUniforms.

Add LayerShader, a class inheriting from SkShader, to mimic the
behavior of SkiaLayerShader. Unlike SkiaLayerShader, it can be set on
the SkPaint so it can be inspected later.
Set a LayerShader instead of a SkiaLayerShader.
setupDrawShader and setupDrawShaderUniforms now inspect an SkShader
passed in.
Inspect SkShader instead of mDrawModifiers.mShader.
Remove resetShader and setupShader.
setupDrawColorUniforms now takes a boolean indicating whether there is
a shader.
Add an inline function for accessing the SkShader on an SkPaint.
In setupDrawBlending(Layer*, bool), do not check the shader (which will
never be set), but do check whether the color filter may change the
alpha (newly fixed behavior).
In setupDrawBlending(SkPaint, ...), check the SkShader and whether the
color filter affects alpha (the latter is new behavior).

Remove pure virtual functions setupShader and resetShader.

Remove functions for refing/unrefing shaders.

Much of this code was redundant and has been removed.
Convert structs into class with nothing but static functions for
calling describe/setupProgram.

Use the SkPixelRef as the key to the bitmap Lru cache, since shader
inspection will provide a different SkBitmap pointer (though it will
hold the correct SkPixelRef with the correct generation ID).

Update manual test to have more shaders: radial, sweep, compose,
invalid compose.


Change-Id: Iaa7189178bda1c55f96da044d2a9fa602ba36034
ecd072161ec57ba8dfb26659511c0f6605601560 27-Mar-2014 Narayan Kamath <narayan@google.com> resolved conflicts for merge of 22d07464 to master

Change-Id: Ic037261eedd6e224938c960d2b4597590c81ed9d
f5df700e6ce056ebfa322314d970e52d6facc35a 25-Mar-2014 Ashok Bhat <ashok.bhat@arm.com> AArch64: Make frameworks/base code more portable

Changes in this patch include

[x] Use %zu for size_t, %zd for ssize_t

[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)

Change-Id: Id1aaa7894a7d0b85ac7ecd7b2bfd8cc40374261f
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
300bdfa13dd903c9335c11838cc0a604d0f8f2e6 26-Feb-2014 Chris Craik <ccraik@android.com> am 328b7ee6: am aecb8c43: am 7b4cce68: am c3bac8a0: Merge "Fix graphics corruption caused by HWUI caches"

* commit '328b7ee6a2ba2dc8f162fa57dbafd4bfc89bb72e':
Fix graphics corruption caused by HWUI caches
36fad8f6fcfbc2087b910600ed5a6f9741177d00 09-Jan-2014 Sangkyu Lee <sk82.lee@lge.com> Fix graphics corruption caused by HWUI caches

Some caches(PatchCache, TextureCache, PathCache) for HWUI
uses deferred removal for their cache entries even though
actual resource objects are immediately freed by
For this reason, the uniqueness of a resource address in
the caches is not guaranteed in specific cases.
(Because malloc() can return the same address when malloc()
and free() called very frequently.)

So it can be possible the cache have two cache entries for
two different resources but the same memory address.
(Of course one of the resources is already freed.)
It also can be possible mGarbage vector in PatchCache has
duplicated addresses and this can lead to duplicated free
blocks in the free block list and graphics corruption.
(Deferred removal was implmeneted based on an assumption of
unique resource addresses.)

So this patch makes sure resource objects are freed after
the resources are removed from the caches to guarantee
the uniqueness of a resource address and prevent graphics

Change-Id: I040f033a4fc783d2c4bc04b113589657c36fb15b
Signed-off-by: Sangkyu Lee <sk82.lee@lge.com>
76d3a1b8d035d27bc80b0f2fc480a903bd001514 10-Dec-2013 Derek Sollenberger <djsollen@google.com> Removing SkiaColorFilter and inspecting the native object directly.

bug: 10650594
Change-Id: I4fcf66d008765afa0e35d011f58bc792183cb74f
d218a92c0afb8c0d98135b20b52ac87236e1c935 03-Jan-2014 Chris Craik <ccraik@google.com> Use const where possible for drawing parameters

They should never be modified by a Renderer, only read and copied.

Change-Id: I9d8d55dca19115ee9dfeb2bb3f092ba2fb327cd4
0c20c3898a533b7b76f60827cb6ea02e17c5953d 02-Jul-2013 Chris Craik <ccraik@google.com> Use global references for Bitmap AndroidPixelRefs


Because we're no longer holding onto Bitmaps Java side during
DisplayList lifetime, use global refs to keep the backing byte arrays

Adds back bitmap buffer passing + native ref management removed by

Adds back globalRef-ing removed by

Change-Id: Ia59ba42f05bea6165aec2b800619221a8083d580
e3b0a0117a2ab4118f868a731b238fe8f2430276 27-Jun-2013 Romain Guy <romainguy@google.com> Refcount 9-patches and properly handle GC events

This change adds refcounting of Res_png_9patch instances, the native
data structure used to represent 9-patches. The Dalvik NinePatch class
now holds a native pointer instead of a Dalvik byte[]. This pointer
is used whenever we need to draw the 9-patch (software or hardware.)

Since we are now tracking garbage collection of NinePatch objects
libhwui's PatchCache must keep a list of free blocks in the VBO
used to store the meshes.

This change also removes unnecessary instances tracking from
GLES20DisplayList. Bitmaps and 9-patches are refcounted at the
native level and do not need to be tracked by the Dalvik layer.

Change-Id: Ib8682d573a538aaf1945f8ec5a9bd5da5d16f74b
547e66531d521eb1eadac87edb0f79f8c2f1bbe0 23-Oct-2012 Chet Haase <chet@google.com> Don't null the reference to Bitmap pixels until we're really ready

A change in the VM triggers a native memory error more aggressively than before,
showing that there's a bug in the logic of recycling bitmaps. Since the pixel
memory is allocated on the Java heap, nulling out the reference to that memory
in the Java level Bitmap object can cause that memory to get collected at any time.
Meanwhile, we may have a reference to that memory at the native level for rendering
purposes, causing an error if/when we access that memory after it has been collected
by the VM.

The fix is to avoid setting the reference to the pixels to null unless we are
not referring to it in native code. This is determined at the time we call
recycle() - we return a boolean to indicate whether the native code is still
using the memory. if not, the Java code can null out the reference and allow the
VM to collect it. Otherwise, it will get collected later when the encompassing
Bitmap object is collected.

Issue #7339156 HTML5 tests crash the app (Vellamo)

Change-Id: I3a0d6b9a6c5dd3b86cc2b0ff7719007e774b5e3c
54643d72f86d0ee0b23e3643ac9257d52ddfae6b 26-Sep-2012 Mathias Agopian <mathias@google.com> make sure to destroy GL objects on the GL thread

Bug: 7195815
Change-Id: I5bcac61cd0b903d1ccca0754fdb9cb1023efbe0f
56257aff8a55c847be72be9924c392033fd8151d 26-Sep-2012 Dave Burke <daveburke@google.com> Revert "Deleting objects on the wrong thread is a silly idea Bug #7195815"

This reverts commit 8a1374946a928fcba7495c87ff6adda327fdfb9f

Change-Id: I53564a6c531d334afcc1fce0bea1e57ae266aa78
8a1374946a928fcba7495c87ff6adda327fdfb9f 26-Sep-2012 Romain Guy <romainguy@google.com> Deleting objects on the wrong thread is a silly idea
Bug #7195815

Turns out that multi-threading is hard.

Change-Id: Ib0b4bd6dc3caea27f7ced22cbb363bb955fe58ab
97dc9172b0e58979c63de0dedbab656399a62281 24-Sep-2012 Romain Guy <romainguy@google.com> Avoid deadlock when deleting layers
Bug #7217459

Change-Id: I12bfa6c30c5030bd1b23ea6a3ce64240ab1dfba3
603f6de35f21d74ae242d52d501f4f5c25ff4f4c 15-Sep-2012 Chet Haase <chet@google.com> Fix occasional crash bug with layers

Launcher occasionally crashes with a stack trace indicating that the memory
of a Layer object is corrupt. It is possible for us to delete a Layer
structure and then, briefly, use it to draw a DisplayList again before
that DisplayList gets recreated (without the layer that got deleted).

When this happens, if the memory got corrupted, it's possible to crash.

The fix is to add Layer to the other objects which we currently refcount
(bitmaps, shaders, etc.). Then instead of deleting a Layer, we decrement the
refcount. We increment when creating it, then increment it again when it's
referenced from a DisplayList. Then we decrement the refcount instead of
deleting it, and decrement when we clear a DisplayList that refers to it.
Then when the refcount reaches 0, we delete it.

Issue #6994632 Native crash in launcher when trying to launch all apps screen

Change-Id: I0627be8d49bb2f9ba8d158a84b764bb4e7df934c
58ecc204fbcacef34806290492384677a330d4d4 07-Sep-2012 Romain Guy <romainguy@google.com> Reduce the number of locks acquired by display lists

Change-Id: I1123aae0355de84db705bb75042c7083fc69c9f2
8dcfd5e836341b4a803b04d104a930bb312182d3 20-Jul-2012 Romain Guy <romainguy@google.com> Clamp gradient textures to max GL texture size

Change-Id: I8ce4e50988f5194fe5ce4bde7945ec01673af3cd
49c5fc0b9e850497233e189ff9dcc71a78ebe6e7 15-May-2012 Romain Guy <romainguy@google.com> Avoid unnecessary copy when invoking drawBitmap(int[])
Bug #6483390

Change-Id: I4d2d725ef50c9401b4bd998b6160128102b40745
5baa3a62a97544669fba6d65a11c07f252e654dd 20-Dec-2011 Steve Block <steveblock@google.com> Rename (IF_)LOGD(_IF) to (IF_)ALOGD(_IF) DO NOT MERGE

See https://android-git.corp.google.com/g/156016

Bug: 5449033
Change-Id: I4c4e33bb9df3e39e11cd985e193e6fbab4635298
6203f6c8147069976342be8f42add797a50f9557 02-Aug-2011 Romain Guy <romainguy@google.com> Reduce the amount of data cached by the gradients cache.

Change-Id: I8546f5a5ecf38031c9a40bdcc434d4c7f22da63d
d586ad9c9fec80aa1d24d6b53cd2c8d5b47fe868 23-Jun-2011 Romain Guy <romainguy@google.com> Fix another memory leak in OpenGLRenderer

Change-Id: I23ed56891452a05cf3ca13f6919c4fef90d5ff4e
6062c5912dc79704b489fc8c289b78a400ed05ee 22-Feb-2011 Derek Sollenberger <djsollen@google.com> Skia Merge (revision 808)

This is a companion CL to the one found in /external/skia

Change-Id: If81748545435cab20a5d8479329ab333cb973e16
5a7e828842c26f64bb6e0ef3e0019e1949b245ee 04-Feb-2011 Chet Haase <chet@google.com> Fix crash when Paths are GCd in hw accelerated apps

A recent change to optimize path rendering didn't account for
the destruction of native objects by the VM finalizer. We may be
done with the Java level version before we're done with the native
structure that's used by the display list. For example, a drawing
method on a View that creates a temporary path to render into the
canvas will implicitly create a native structure that is put onto
the GL display list. That temporary path may go away, but the native
version should stick around as long as the display list does.

The fix is to refcount the original native version of the path
and only delete it when the refcoutn reaches zero (which means that
it is no longer needed by any display list). This is a similar mechanism
used for bitmaps and shaders.

Change-Id: I4de1047415066d425d1c689aa60827f97729b470
43ccf4663c822ddd435b7683cc05221f6169c6c3 15-Jan-2011 Romain Guy <romainguy@google.com> Don't crash Launcher on config change.

Change-Id: Ibbbd7146c5ff69e9639b433f39041053654d808c
f890fab5a6715548e520a6f010a3bfe7607ce56e 20-Dec-2010 Patrick Dubroy <dubroy@google.com> Ensure bitmaps aren't freed while referenced from a display list

Also removes the reference queue finalizers. They aren't necessary
anymore now that Bitmaps are allocated in the heap.
e4ac2d6b5723c95e648c489b187ddde449452c13 01-Dec-2010 Patrick Dubroy <dubroy@google.com> Allocate bitmap backing buffers in the Java heap.

Change-Id: I60f6ccff13357c1c518e9d56b02fe0171637edd1
5cafc52fb10bd05c587a7dec41c953c0722f302a 23-Nov-2010 Chet Haase <chet@google.com> Fix hang in native bitmap recycling due to nested mutex locks

Change-Id: Ic37d5408ddb3f68aba6520fb0c78ffde91dfbe62
e7d2295c06ef9b9df6336cbff23007a13fb3f6e4 12-Nov-2010 Chet Haase <chet@google.com> make ResourceCache for display lists thread-safe

Change-Id: I41885b4ae249d7d7c000bab17bf32340ba85ab3a
fe48f65922d4a3cc4aefe058cee5acec51504a20 12-Nov-2010 Romain Guy <romainguy@google.com> Free resources only from the GL context thread.
Bug #3179882

Resources were freed following garbage collections on a worker thread.
This worker thread had no EGL context, which would cause the renderer
to incorrectly assume that the memory was liberated.

Change-Id: Ifdb51f94ddf42641e8654522787bfac532976c7c
ad93c2bb63dfc813b2eefa1043aa63afbddce655 23-Oct-2010 Chet Haase <chet@google.com> Optimizing ColorFilter in display lists

Change-Id: Ie4d5e5b0bc45e0ce47bba144049303c270762e54
d98aa2de9ab18e09c2be1997f41212740f51f6e6 26-Oct-2010 Chet Haase <chet@google.com> DisplayList optimizations and fixes.

We now use a copy of SkPaint objects to avoid having it changed from under us.
We reuse copies that have not changed. We also copy the SkMatrix every time to
avoid the same problem.

Change-Id: If3fd80698f2d43ea16d23302063e0fd8d0549027
5c13d89c1332fcc499379b9064b891187b75ca32 08-Oct-2010 Chet Haase <chet@google.com> Optimizing display lists by referencing pointers to resources instead of copying them

Change-Id: I81ad3551d74aa1e5bb64d69e33d2eb29a6c1eb6a