| 6a2d17f71342f981c9df1dc5beff33e30eb3ae2b |
|
30-Sep-2012 |
Chet Haase <chet@google.com> |
Fix texture corruption
When memory gets low on a device, activities flush everything they can.
Hardware-accelerated activites, such as Launcher, flush GL resources and destroy
the GL context. However, some resources were still hanging around, due to deferred
destruction policies (we don't delete layers until the DisplayLists they are in
are finalized, to ensure we don't deref deleted objects). This meant that we were
referring to obsolete GL data in these objects. in particular, it meant that we might
come around later, after a new GL context was created, and delete a texture object
that was incorrect. We use the layer's "texture id" to refer to the texture underlying the
layer. But if there's a new GL context, then this texture ID is no longer valid, and
we may be deleting the texture that a different object (layer, icon, whatever) is referring
to, because the driver may return that same ID under the new GL context.
The fix is to more aggressively delete things that we know will not be used again
when the GL context is destroyed. In particular, we delete all resources being used
by all DisplayLists at GL context destruction time.
Issue #7195815 Textures corruption on all devices, in many apps
Change-Id: I52d2d208173690dbb794a83402d38f14ea4c6c22
/frameworks/base/core/java/android/view/GLES20DisplayList.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/GLES20DisplayList.java
|
| 0d6f4c06df0b0e35125f088ca028c7226b274dc4 |
|
21-Jun-2012 |
Romain Guy <romainguy@google.com> |
Dejank: don't allocate when scrolling lists
The new display list properties introduces in JB were causing numerous
and expensive memory allocations while scrolling lists. During a scroll
ListView sometimes attempts to apply an offset to views before they are
drawn for the first time. This had the side effect of generating a new
IllegalStateException and its entire stack trace. The exception was
caught inside the display list and never seen by users.
Generating an exception is very expensive both in terms of allocated
memory and CPU time spent crawling the stack.
List scrolls/flings are a common case of this issue but it also happens
during various types of animations. A simple alpha animation, for instance,
can cause the problem to occur.
Another side effect of this issue is more frequent and longer GC pauses.
Change-Id: Ic1b37cc84f7c8f290209cfb990d030e96d6e0dc7
/frameworks/base/core/java/android/view/GLES20DisplayList.java
|
| 38c2ece5ce4c59f30e5832779bf1d86d68b1c442 |
|
24-May-2012 |
Romain Guy <romainguy@google.com> |
Clear bitmap references from display lists as early as possible
Bug #6555840
Apps like Google+ with large bitmaps displayed in listivews could
run into memory issues because of these references.
Change-Id: I39486bda13ce00c5a3b6481139ad54547506a8b4
/frameworks/base/core/java/android/view/GLES20DisplayList.java
|
| afd5c3ee60c45ebb5d63d2d0d14f08130075883b |
|
10-May-2012 |
Chet Haase <chet@google.com> |
Clear animations in DisplayLists when done
The matrix calculated by Animations is pushed down to the native
DisplayList object, and is then used when the DL is issued to the
GL renderer. This works while the animation is running, but the end
of animations is not handled correctly. In particular, we never clear the
animation, so whatever the last frame of the animation calculated will
persist on that DisplayList object until it is recreated.
The fix is to note when we used to be animating and are no longer
doing so, taking that opportunity to push the cleared state down
to the DisplayList.
Issue #6448993 action bar -- including settings menu -- disappears on Nakasi
Change-Id: I73cdadaef40d87ccbc1beb02599c4d70506ea42b
/frameworks/base/core/java/android/view/GLES20DisplayList.java
|
| db8c9a6a4d9bf8c39f834b25611926caf21380f6 |
|
22-Mar-2012 |
Chet Haase <chet@google.com> |
Optimization of alpha with DisplayList properties
Some views (such as ImageView and TextView) handle non-opaque alpha
values directly. This was originally an optimization, but we can handle it faster
in many cases without this optimization when DisplayList properties are enabled.
Basically, if a view has non-overlapping rendering, we set the alpha value directly
on the renderer (the equivalent of setting it on the Paint object) and draw each
primitive with that alpha value. Doing it this way avoids re-creating DisplayLists
while getting the same speedup that onSetAlpha() used to get pre-DisplayList properties.
Change-Id: I0f7827f075d3b35093a882d4adbb300a1063c288
/frameworks/base/core/java/android/view/GLES20DisplayList.java
|
| 9420abd56a2af7ddbeb70562b79d61b2dca8c5a1 |
|
30-Mar-2012 |
Chet Haase <chet@google.com> |
Re-enable DisplayList properties.
Re-enabling DisplayList properties last week caused some app
errors due to the way that some transforms were being handled (specifically,
those coming from the old Animations and ViewGroup's childStaticTransformation
field). This change pushes *all* transform/alpha data from View.draw() into
the view's DisplayList, making DisplayLists more encapsulated (and correct).
Change-Id: Ia702c6aae050784bb3ed505aa87553113f8a1938
/frameworks/base/core/java/android/view/GLES20DisplayList.java
|
| a1cff5043d0fbd78fcf9c48e7658e56a5b0c2de3 |
|
21-Feb-2012 |
Chet Haase <chet@google.com> |
Handle view properties at the native level
Basic functionality of handling View properties (transforms,
left/right/top/bottom, and alpha) at the native DisplayList level.
This logic is disabled for now (via compile-time flags in View.java and
DisplayListRenderer.h) as we continue work on it (there is no advantage
to the new approach until we optimize invalidation and rendering paths
to use the new code path).
Change-Id: I370c8d21fbd291be415f55515ab8dced6f6d51a3
/frameworks/base/core/java/android/view/GLES20DisplayList.java
|
| 13631f3da855f200a151e7837ed9f6b079622b58 |
|
31-Jan-2012 |
Romain Guy <romainguy@google.com> |
Add debug markers to OpenGLRenderer
These markers will be used to group the GL commands by View in the
OpenGL ES debugging tool. This will help correlate individual GL
calls to higher level components like Views.
Change-Id: I73607ba2e7224a80ac32527968261ee008f049c6
/frameworks/base/core/java/android/view/GLES20DisplayList.java
|
| b35ab7b72967adcfd01cec483a705dafe8b951d1 |
|
06-Dec-2011 |
Gilles Debunne <debunne@google.com> |
Sub display list in TextView
TextView uses a sub-display list to 'cache' the rendering of its
text. This saves time when drawing an editable text, where the blinking
cursor forces a re-draw twice per second, which creates pauses during
scrolling.
Added a sub-display list invalidation when an appearance span is
modified/added/removed.
Also added an invalidation of the display list when selection range
is changed.
Change-Id: I41e8068a12902b8a745c5bb77de8c77def76a270
/frameworks/base/core/java/android/view/GLES20DisplayList.java
|
| 65b345fa22b878e141b8fd8ece9c208df00fa40f |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Reclaim more memory, more often.
Yay.
Change-Id: I04557ad575c307a55088549f48f0e9ad994b7275
/frameworks/base/core/java/android/view/GLES20DisplayList.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/GLES20DisplayList.java
|
| d6cf477e5d6245a63f71958b75c3d658cd6c100e |
|
05-Mar-2011 |
Romain Guy <romainguy@google.com> |
Remove many unnecessary save/restore calls.
This should help complex applications by reducing the amount of
unnecessary work performed by the renderer.
Change-Id: I9bdebb1a35cdbcc3d926b7485f19d9e88a019040
/frameworks/base/core/java/android/view/GLES20DisplayList.java
|
| daf98e941e140e8739458126640183b9f296a2ab |
|
10-Jan-2011 |
Chet Haase <chet@google.com> |
Use optimized display lists for all hwaccelerated rendering
Previously, display lists were used only if hardware acceleration
was enabled for an application (hardwareAccelerated=true) *and* if
setDrawingCacheEnabled(true) was called. This change makes the framework
use display lists for all views in an application if hardware acceleration
is enabled.
In addition, display list renderering has been optimized so that
any view's recreation of its own display list (which is necessary whenever
the visuals of that view change) will not cause any other display list
in its parent hierarchy to change. Instead, when there are any visual
changes in the hierarchy, only those views which need to have new
display list content will recreate their display lists.
This optimization works by caching display list references in each
parent display list (so the container of some child will refer to its
child's display list by a reference to the child's display list). Then when
a view needs to recreate its display list, it will do so inside the same
display list object. This will cause the content to get refreshed, but not
the reference to that content. Then when the view hierarchy is redrawn,
it will automatically pick up the new content from the old reference.
This optimization will not necessarily improve performance when applications
need to update the entire view hierarchy or redraw the entire screen, but it does
show significant improvements when redrawing only a portion of the screen,
especially when the regions that are not refreshed are complex and time-
consuming to redraw.
Change-Id: I68d21cac6a224a05703070ec85253220cb001eb4
/frameworks/base/core/java/android/view/GLES20DisplayList.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/GLES20DisplayList.java
|
| 5977baa1fa24125c148a72699b53e62abaf08960 |
|
06-Jan-2011 |
Chet Haase <chet@google.com> |
Reuse of native display list objects
Change-Id: Ia4553e23930ad20e56c11faa7809be788a1ad4bb
/frameworks/base/core/java/android/view/GLES20DisplayList.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/GLES20DisplayList.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/GLES20DisplayList.java
|
| 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/core/java/android/view/GLES20DisplayList.java
|
| b051e895ccb696604349c6c5efe7c4747e1d1ab6 |
|
29-Sep-2010 |
Romain Guy <romainguy@google.com> |
Add display lists caching.
Change-Id: Iac3a248a81ed8cb076a83ef9d186b8ebba685b4c
/frameworks/base/core/java/android/view/GLES20DisplayList.java
|