| 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/core/java/android/view/GLES20RecordingCanvas.java
|
| 16c0318474c60bdbed04ded25dc4ffea8991857a |
|
17-Jun-2013 |
Romain Guy <romainguy@google.com> |
Lazily allocate seldom-used data structures
Change-Id: I8d6b9d2d821168329206c01ed6539a1466af272f
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| 3b748a44c6bd2ea05fe16839caf73dbe50bd7ae9 |
|
18-Apr-2013 |
Romain Guy <romainguy@google.com> |
Pack preloaded framework assets in a texture atlas
When the Android runtime starts, the system preloads a series of assets
in the Zygote process. These assets are shared across all processes.
Unfortunately, each one of these assets is later uploaded in its own
OpenGL texture, once per process. This wastes memory and generates
unnecessary OpenGL state changes.
This CL introduces an asset server that provides an atlas to all processes.
Note: bitmaps used by skia shaders are *not* sampled from the atlas.
It's an uncommon use case and would require extra texture transforms
in the GL shaders.
WHAT IS THE ASSETS ATLAS
The "assets atlas" is a single, shareable graphic buffer that contains
all the system's preloaded bitmap drawables (this includes 9-patches.)
The atlas is made of two distinct objects: the graphic buffer that
contains the actual pixels and the map which indicates where each
preloaded bitmap can be found in the atlas (essentially a pair of
x and y coordinates.)
HOW IS THE ASSETS ATLAS GENERATED
Because we need to support a wide variety of devices and because it
is easy to change the list of preloaded drawables, the atlas is
generated at runtime, during the startup phase of the system process.
There are several steps that lead to the atlas generation:
1. If the device is booting for the first time, or if the device was
updated, we need to find the best atlas configuration. To do so,
the atlas service tries a number of width, height and algorithm
variations that allows us to pack as many assets as possible while
using as little memory as possible. Once a best configuration is found,
it gets written to disk in /data/system/framework_atlas
2. Given a best configuration (algorithm variant, dimensions and
number of bitmaps that can be packed in the atlas), the atlas service
packs all the preloaded bitmaps into a single graphic buffer object.
3. The packing is done using Skia in a temporary native bitmap. The
Skia bitmap is then copied into the graphic buffer using OpenGL ES
to benefit from texture swizzling.
HOW PROCESSES USE THE ATLAS
Whenever a process' hardware renderer initializes its EGL context,
it queries the atlas service for the graphic buffer and the map.
It is important to remember that both the context and the map will
be valid for the lifetime of the hardware renderer (if the system
process goes down, all apps get killed as well.)
Every time the hardware renderer needs to render a bitmap, it first
checks whether the bitmap can be found in the assets atlas. When
the bitmap is part of the atlas, texture coordinates are remapped
appropriately before rendering.
Change-Id: I8eaecf53e7f6a33d90da3d0047c5ceec89ea3af0
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| da12f389eb4be0c08ca3fa9ca7663f4977858df5 |
|
15-Mar-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
Revert "Clean Paint.mBidiFlags as it is no longer used"
This reverts commit 6d9fe5bd22b531bfce69b146254a4791c76acddc.
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| 6d9fe5bd22b531bfce69b146254a4791c76acddc |
|
12-Feb-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
Clean Paint.mBidiFlags as it is no longer used
See bug #7623824
Change-Id: Ie2f9422821f6dcc73c99e8695f448e966b587b1d
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| ef35927abcd089652f87a985dd6dde7afde58b92 |
|
01-Feb-2013 |
Romain Guy <romainguy@google.com> |
Tag HardwareRenderers with a name to help debugging
The name of the renderer is the same as the window it belongs to.
Change-Id: Ie9adc0a1978afa026923ea41f5540eda6ba65a92
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| abae2a1b891772d36d8f781adfcc8969e551691f |
|
28-Nov-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Simplification of the poolable management utils.
Before to implement a pool of objects, the pooled class had to implement an
interface which was leaking the pool management APIs. This requires
hiding APIs - inconvenient at best. Further, each client had to
implement the chaining of pooled instances which means adding a couple
of member variables which are manipulated by the implemented interface
methods. As a consequence the client is aware of how pooling is
implemented which is error prone and breaks encapsulation. Now the
pool objects are responsible for managing pooling state via reusable
wrapper objects and the clients are oblivious of how pooling is done.
Creating a thin cached wrapper for each pooled object has minimal
performance impact while making the code more maintainable. Actually
implementing of the old version of the APIs was taking as much code
as implementing the pooling yourself.
Also clients had to implement a poolable manager whose responsibility
was to create new instances and provide callbacks when an instance
is added to or removed from the pool. Now, the clinet class should
create a static member for the pool and expose obtain/aquire and
release/recycle methods in which it should create a new instance if
the pool did not return one and clear the state of the host when
it is returned to the pool. Updated the JavaDoc with a best practice.
The pooling was composed of several interfaces and classes scattered
over a few files, now all this is in a single small file.
Update all usages of the pooling APIs in the framework.
Also one had to write a poolable
manager which
Change-Id: Ib8dc286040eb3d7cb7d9668ba76fead05cb97647
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| dfab363807b3b44be4032e410f016e0a0d018426 |
|
03-Oct-2012 |
Romain Guy <romainguy@google.com> |
Fix rendering artifacts on tiled renderers
Bug #7275145
This change fixes ViewRoot and adds extra debug information. It does
not solve the problem entirely. Another CL will.
Change-Id: I7e604ba38aad7f421769783dcbd998d6905ab2d9
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| ca479d468be963661fd82634f4b57f21c13f1fe6 |
|
31-Aug-2012 |
Chet Haase <chet@google.com> |
Make detachViewFromParent more robust
Calling detachViewFromParent() without calling remove or attach in the
same drawing frame could, in some situations, cause a crash in the native
DisplayList code. detach/attach are intended to be very lightweight and do
not manage the native DisplayList content the same way that add/remove do.
Nor do they cause an invalidate() or requestLayout(), which would cause the
native structures to get recreated appropriately.
This fix makes this process more robust in two ways:
- DisplayLists should not get finalized (therefore destroying their native
structures) when there are still parent DisplayLists referring to them
(each DisplayList keeps references to its child DisplayLists). This will
prevent the native crash associated with unmatched detach*() calls.
- The docs for detach/attach have been enhanced to make it easier for
developers to understand how to use these methods more correctly and
successfully.
Issue #7064818 detachViewFromParent() should be more robust
Change-Id: I53befc04d5d58c225060f397725566d470488c9b
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| 33f6beb10f98e8ba96250e284876d607055d278d |
|
17-Feb-2012 |
Romain Guy <romainguy@google.com> |
Record possible clip rejects when recording display lists
This optimization allows us to quickly skip operations that lie
entirely outside of the known bounds of a display list. Because
of ViewGroup.setClipChildren, we must keep the operations recorded
in the display list. setClipChildren(false) is however a very
uncommon operation and we will therefore often benefit from this
new optimization.
Change-Id: I0942c864e55298e6dccd9977d15adefbce3ba3ad
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| 6d7475d666baefaa3ba9f0dcee25238739454241 |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Destroy layers and flush layers cache when a window is destroyed.
Change-Id: I3fa1bc3ff50fb99e3d2e490925bd6b0a0f809fff
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| 162a0217563f4665da6eb183dfce0fef740f641f |
|
22-Jul-2011 |
Jeff Brown <jeffbrown@google.com> |
Decouple GLES20RecordingCanvas lifetime from GLES20DisplayList.
Bug: 5062011
Previously, each GLES20DisplayList would hold onto an instance of
GLES20RecordingCanvas. In turn, each GLES20RecordingCanvas
held onto an SkWriter with a 16Kb buffer along with several other
objects. With one display list per view and hundreds of views,
the overhead could add up to a few megabytes.
Ensured that the GLES20RecordingCanvas is reset as soon as
the display list has been constructed, thereby promptly freeing
the 16Kb buffer.
Changed GLES20DisplayList so that it acquires a GLES20RecordingCanvas
from a pool as needed and recycles it when done.
Removed some dead code and cruft related to the construction of
GLES20Canvas objects in general. Some code was written with the
assumption that the underlying renderer object could change
behind the scenes or might be lazily constructed, but that isn't
actually the case so we can simplify things.
Removed an unnecessary weak reference from GLES20DisplayList
to the View. It isn't actually used anywhere.
Fixed a bug in GLES20DisplayList where isValid() would return
true while the display list was being recorded. This is incorrect
because the native display list might not actually exist. Worse,
even if the native display list does exist, it is stale and
potentially refers to old Bitmaps that have been GC'd (because the
mBitmaps list was cleared when recording started).
Change-Id: Ib12d5483688cb253478edeb0156d34c476c2566b
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| b39f051631250c49936a475d0e64584afb7f1b93 |
|
24-May-2011 |
Chet Haase <chet@google.com> |
Add 'Property' object
This change adds a generic Property facility to the SDK, which allows an
easy way to reference fields (private or otherwise) in a general way.
For example, animations can use this facility to animate 'properties'
on target objects in a way that is more code- and compiler-friendly than
the existing String-based approach (for objects which have implemented
Properties, of course). The animator classes have been updated to use
this new approach (in addition to Strings, which are still more generally
useful for objects which have get/set functions but not Property objects).
The change also includes new Property objects on View (which can now be
used in creating animations on Views).
There is an unrelated change on GLES20RecordingCanvas to change the way we
cache bitmaps, which avoids spurious garbage by using an ArrayList instead of
a HashSet.
Change-Id: I167b43a3fca20e7695b1a23ca81274367539acda
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| 6c319ca1275c8db892c39b48fc54864c949f9171 |
|
11-Jan-2011 |
Romain Guy <romainguy@google.com> |
Better backend for hardware layers.
With this new backend, a hardware layer is only recreated when
its associated view is udpated. This offers fast composition
in GL and fast update of the layer in GL as well.
Change-Id: I97c43a612f5955c6bf1c192c8ca4af10fdf1d076
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| 9e90a9953b65ae575ec8db3989857e0c145724b1 |
|
05-Jan-2011 |
Chet Haase <chet@google.com> |
Reuse display lists at the java level.
Objects are invalidated and reset instead of being nulled out
and recreated. This avoids creating small amounts of garbage for
the display list and canvas objects.
Change-Id: I464fac7ea8944c19ad6d03f13a95d9017e3f4262
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|
| 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.
/frameworks/base/core/java/android/view/GLES20RecordingCanvas.java
|