History log of /frameworks/base/libs/hwui/ResourceCache.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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
/frameworks/base/libs/hwui/ResourceCache.h
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
/frameworks/base/libs/hwui/ResourceCache.h
97dc9172b0e58979c63de0dedbab656399a62281 24-Sep-2012 Romain Guy <romainguy@google.com> Avoid deadlock when deleting layers
Bug #7217459

Change-Id: I12bfa6c30c5030bd1b23ea6a3ce64240ab1dfba3
/frameworks/base/libs/hwui/ResourceCache.h
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
/frameworks/base/libs/hwui/ResourceCache.h
58ecc204fbcacef34806290492384677a330d4d4 07-Sep-2012 Romain Guy <romainguy@google.com> Reduce the number of locks acquired by display lists

Change-Id: I1123aae0355de84db705bb75042c7083fc69c9f2
/frameworks/base/libs/hwui/ResourceCache.h
7953745dd565167113f8cbfc461bc0521d32d870 12-Oct-2011 Romain Guy <romainguy@google.com> Reduce the size of libhwui by 50%

This change removes unnessary symbols. All symbols are hidden by
default, public APIs with exported symbols are explicitly marked
with ANDROID_API.

Change-Id: I692fde432a86c12108de1cfd1f6504919a7d5f3f
/frameworks/base/libs/hwui/ResourceCache.h
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
/frameworks/base/libs/hwui/ResourceCache.h
5cafc52fb10bd05c587a7dec41c953c0722f302a 23-Nov-2010 Chet Haase <chet@google.com> Fix hang in native bitmap recycling due to nested mutex locks

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

Change-Id: I41885b4ae249d7d7c000bab17bf32340ba85ab3a
/frameworks/base/libs/hwui/ResourceCache.h
5b3b35296e8b2c8d3f07d32bb645d5414db41a1d 28-Oct-2010 Romain Guy <romainguy@google.com> Optimize FBO drawing with regions.
This optimization is currently disabled until Launcher is
modified to take advantage of it. The optimization can be
enabled by turning on RENDER_LAYERS_AS_REGIONS in the
OpenGLRenderer.h file.

Change-Id: I2fdf59d0f4dc690a3d7f712173ab8db3848b27b1
/frameworks/base/libs/hwui/ResourceCache.h
ad93c2bb63dfc813b2eefa1043aa63afbddce655 23-Oct-2010 Chet Haase <chet@google.com> Optimizing ColorFilter in display lists

Change-Id: Ie4d5e5b0bc45e0ce47bba144049303c270762e54
/frameworks/base/libs/hwui/ResourceCache.h
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
/frameworks/base/libs/hwui/ResourceCache.h
5c13d89c1332fcc499379b9064b891187b75ca32 08-Oct-2010 Chet Haase <chet@google.com> Optimizing display lists by referencing pointers to resources instead of copying them

Change-Id: I81ad3551d74aa1e5bb64d69e33d2eb29a6c1eb6a
/frameworks/base/libs/hwui/ResourceCache.h