History log of /frameworks/base/core/java/android/view/HardwareCanvas.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
680df8d60e3445bd14df902796079d730c283c46 20-Nov-2014 John Reck <jreck@google.com> Rename callDrawGLFunction

Bug: 18471503
Change-Id: I00cb356ff2338da7fd07b9ba30b5b3dcbdffdb2e
/frameworks/base/core/java/android/view/HardwareCanvas.java
072707dfad1da6f49f4d3ce58ca104f6c46a7266 15-Sep-2014 Jorim Jaggi <jjaggi@google.com> Use RenderThread for navigation bar ripples

Bug: 17506181
Change-Id: Icf3b80f8c4bc29fe85313381d4019dda3ef85ea9
/frameworks/base/core/java/android/view/HardwareCanvas.java
362dd6d632f0eb63de4edf4a6eec281342391d9f 09-Jul-2014 Jorim Jaggi <jjaggi@google.com> Add glyph rerasterization hack for SystemUI.

Change-Id: I39d84e981b828b501801349d7a5e70a089b5f14e
/frameworks/base/core/java/android/view/HardwareCanvas.java
a7090e0cfd7c719a6d4c03aae34f5db98754cbdd 21-Jun-2014 Chris Craik <ccraik@google.com> Update 'DisplayList' vs 'RenderNode' naming in several places

Change-Id: I635c6627d098b661fb9b0ba1bd42fa6d7277d287
/frameworks/base/core/java/android/view/HardwareCanvas.java
84a4c887a07c1c2939443f4e0587d7f1ac109e4b 30-May-2014 John Reck <jreck@google.com> Remove GLRenderer

Change-Id: I180286417c1a354fc7eb1eadb1884ac6add0795c
/frameworks/base/core/java/android/view/HardwareCanvas.java
832b151465ed81c43e59891d5eebe62128b21fbb 07-May-2014 John Reck <jreck@google.com> Cleanup attachFunctor

Bug: 13961296

Change-Id: Id48d11bfcc234afd1fd7e4fdd409a50e7208c81d
/frameworks/base/core/java/android/view/HardwareCanvas.java
52244fff29042926e21fa897ef5ab11148e35299 02-May-2014 John Reck <jreck@google.com> Add CanvasProperty for drawCircle

Change-Id: Icbcc030f5033d2094e567d7c519b9d672f2aac1c
/frameworks/base/core/java/android/view/HardwareCanvas.java
750ca6dbdb259aea0ca5b77380a9303e586ef3ea 29-Mar-2014 John Reck <jreck@google.com> Remove kStatusInvoke & kStatusDraw

They are unused

Change-Id: I44ecf1164dc6bc1b09438e733976d5a97a25f00e
/frameworks/base/core/java/android/view/HardwareCanvas.java
f666ad7046c0b1b255835f75aeb7d1391067df93 15-Mar-2014 John Reck <jreck@google.com> Rename DisplayList->RenderNode

Change-Id: Idcca6f26ba6282594789962f5edb3ed53a290fef
/frameworks/base/core/java/android/view/HardwareCanvas.java
36bef0bf30d6bae48cf3837df351075ca4fce654 20-Jan-2014 Ashok Bhat <ashok.bhat@arm.com> AArch64: Make graphics classes 64-bit compatible

This a merger of two commits submitted to AOSP by
the following authors:

ashok.bhat@arm.com, david.butcher@arm.coma
craig.barber@arm.com, kevin.petit@arm.com and
marcus.oakland@arm.com

Due to the very large number of internal conflicts, I
have chosen to cherry-pick this change instead
of letting it merge through AOSP because the merge
conflict resolution would be very hard to review.

Commit messages below:

================================================
AArch64: Make graphics classes 64-bit compatible

Changes in this patch include

[x] Long is used to store native pointers as they can
be 64-bit.

[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)

[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.

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>

==================================================================

AArch64: Use long for pointers in graphics/Camera

For storing pointers, long is used in
android/graphics/Camera class, as native
pointers can be 64-bit.

In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use of
jint instead of int in JNI function prototypes)

Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>

===================================================================

Change-Id: Id5793fa0ebc17ee8b1eecf4b3f327977fdccff71
/frameworks/base/core/java/android/view/HardwareCanvas.java
7023df08f14ec5dee76ac54c03e870f84e297636 27-Jan-2014 Narayan Kamath <narayan@google.com> Revert "AArch64: Make graphics classes 64-bit compatible"

This reverts commit 18b4cbeedef21c1fa666a110a157bab66edff976.

Change-Id: I0c52983a3ab1ace3ff743de546a43eca28e5cb0e
/frameworks/base/core/java/android/view/HardwareCanvas.java
18b4cbeedef21c1fa666a110a157bab66edff976 20-Jan-2014 Ashok Bhat <ashok.bhat@arm.com> AArch64: Make graphics classes 64-bit compatible

This a merger of two commits submitted to AOSP by
the following authors:

ashok.bhat@arm.com, david.butcher@arm.coma
craig.barber@arm.com, kevin.petit@arm.com and
marcus.oakland@arm.com

Due to the very large number of internal conflicts, I
have chosen to cherry-pick this change instead
of letting it merge through AOSP because the merge
conflict resolution would be very hard to review.

Commit messages below:

================================================
AArch64: Make graphics classes 64-bit compatible

Changes in this patch include

[x] Long is used to store native pointers as they can
be 64-bit.

[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)

[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.

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>

==================================================================

AArch64: Use long for pointers in graphics/Camera

For storing pointers, long is used in
android/graphics/Camera class, as native
pointers can be 64-bit.

In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use of
jint instead of int in JNI function prototypes)

Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>

===================================================================

Change-Id: Ib3eab85ed97ea3e3c227617c20f8d213f17d4ba0
/frameworks/base/core/java/android/view/HardwareCanvas.java
2114aef4eaa1c6539d4fe83bb130395dad7fbae7 15-Jan-2014 John Reck <jreck@google.com> Remove dead code

Change-Id: I9c96d3d21bd3faed91a5146f5a2b8916c634fdff
/frameworks/base/core/java/android/view/HardwareCanvas.java
630491973269da1b260e69d6a3f9490b97705037 11-Dec-2013 John Reck <jreck@google.com> Unbreak display list debug dumping

Change-Id: I1c6a79f047b29fa60907f6e128cb843a45b88bff
/frameworks/base/core/java/android/view/HardwareCanvas.java
e93482f5eac3df581d57e64c2a771a96aa868585 17-Jun-2013 Romain Guy <romainguy@google.com> Cancel layer update when a layer is about to be destroyed
Bug #9310706

Change-Id: I73eea6314c326f15a979617e3a05b525935f0d3f
/frameworks/base/core/java/android/view/HardwareCanvas.java
405436021da156fbe3c5d4de48bdefa564cf7fc0 13-Jun-2013 Romain Guy <romainguy@google.com> Restore buildLayer()'s old behavior; it's synchronous again
Bug #9193833

Change-Id: I4ee07e65c0a8967f0b55da030ecaad6dfc46136f
/frameworks/base/core/java/android/view/HardwareCanvas.java
52036b19a5f82bc4d75cfcbff99c65df8d25a99b 15-Feb-2013 Romain Guy <romainguy@google.com> Expose display list APIs

The exposed APIs are slightly simpler than the full APIs used internally.
Only APIs useful to applications are exposed.

Change-Id: Ie03014628d40ad5ef63dedbc52ce3def84429d54
/frameworks/base/core/java/android/view/HardwareCanvas.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/HardwareCanvas.java
11cb642756093a4af901b1525375b1eb2b5c3e2b 21-Sep-2012 Romain Guy <romainguy@google.com> Update layers in a single batch at the beginning of a frame
Bug #7186819

Change-Id: Ice5926dfedfb3be3a3064e65008dafa2852407da
/frameworks/base/core/java/android/view/HardwareCanvas.java
44b2fe3fc114ee5f7273c6b0fee2cc999bf244a2 07-Jun-2012 Chet Haase <chet@google.com> Track canvas clearing for swap buffers logic.

A previous fix made it necessary for a frame to render something to GL
in order to cause a call to eglSwapBuffers(). Besides the calls being
tracked as part of issuing a DisplayList, there is also a potential call
to clear the canvas (via glClear()) on non-opaque surfaces. This call is also
good to track, since a surface that gets cleared without any other drawing operations
is worth flipping to the screen (to erase old contents on that surface).

This fix tracks the status of the pre-draw operations to find out whether
glClear() was called and then sets the drawing status appropriately.

Issue #6606422 QuickContact dismissal is janky again (Tracking)

Change-Id: I5fcaccfdc9293dd46b83f2fc279730a5d2740ebf
/frameworks/base/core/java/android/view/HardwareCanvas.java
ba6be8a62dcdb3ffd210cd36b9af4e3a658eac47 24-Apr-2012 Romain Guy <romainguy@google.com> Prevent WebView from crashing when detached from the window
Bug #6365056

WebView enqueues a functor in the hardware renderer to handle
animations and this functor is called at a later time by the
hardware renderer. However, the functor was not removed from
the queue when WebView was removed from the window. This could
cause the hardware renderer to attempt to execute an invalid
functor and lead to a crash.

Change-Id: I9d38e80f3fdc5e29d4d0cdfa1e893c251a954508
/frameworks/base/core/java/android/view/HardwareCanvas.java
1271e2cc80b01d577e9db339459ef0222bb9320d 20-Apr-2012 Chet Haase <chet@google.com> Remove USE_DISPLAY_LIST_PROPERTIES flag

This flag was still hanging around pending any need to disable
DisplayList properties. But things seem stable, so it's time to clean up
and simplify the code.

At the same time, I reduced redundance in DisplayList dimensions. We
used to call drawDisplayList() with width/height parameters that were
used to do a clip reject. This is redundant with the DisplayList properties
that set the bounds of the DisplayList; the left/right and top/bottom properties
represent the same width/height properties formerly used in drawDisplayList().
The new approach is to not pass dimensions to drawDisplayList(), but to
instead pull those dimensions directly from the DisplayList when needed.

Change-Id: I8871beff03b1d4be95f7c6e079c31a71d31e0c56
/frameworks/base/core/java/android/view/HardwareCanvas.java
8f3b8e32993d190a26c70c839a63d8ce4c3b16d9 28-Mar-2012 Romain Guy <romainguy@google.com> Allow fine-grained control over functors execution

Adds non-drawing execution mode

Change-Id: I82f92cf1b9a3b9ff2ca6d7427c4e02b73e04e6bf
/frameworks/base/core/java/android/view/HardwareCanvas.java
6554943a1dd6854c0f4976900956e556767b49e1 27-Mar-2012 Romain Guy <romainguy@google.com> Use a status_t return type for GL functors

WebView needs more fine-grained control over the behavior of the
framework upon execution of the display lists. The new status_t
allows WebView to requests its functor to be re-executed directly
without causing a redraw of the entire hierarchy.

Change-Id: I97a8141dc5c6eeb6805b6024cc1e76fce07d24cc
/frameworks/base/core/java/android/view/HardwareCanvas.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/HardwareCanvas.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/HardwareCanvas.java
ed30fd8e9a2d65ee5c8520de55b0089c219f390c 23-Apr-2011 Chet Haase <chet@google.com> Add ability for hierarchyviewer to output displaylist info

Clicking on a node in hierarchyviewer1 and hierarchyviewer2 and then
clicking the new "Dump DisplayList" button will cause the display
list for the selected node (including its children) to be output into
logcat.

Change-Id: Iad05f5f6cca0f8b465dccd962b501dc18fe6e053
/frameworks/base/core/java/android/view/HardwareCanvas.java
a17de9b493123f0d6e6d0b842150bf29322b7a88 05-May-2011 Chet Haase <chet@google.com> Revert "Add ability for hierarchyviewer to output displaylist info"

This reverts commit b2a4b52e8d5e499d33e2765e8c47851bf0266299.
/frameworks/base/core/java/android/view/HardwareCanvas.java
b2a4b52e8d5e499d33e2765e8c47851bf0266299 23-Apr-2011 Chet Haase <chet@google.com> Add ability for hierarchyviewer to output displaylist info

Clicking on a node in hierarchyviewer1 and hierarchyviewer2 and then
clicking the new "Dump DisplayList" button will cause the display
list for the selected node (including its children) to be output into
logcat.

Change-Id: Id32f62569ad1ab4d533bc62987f3a7390c1bb4e6
/frameworks/base/core/java/android/view/HardwareCanvas.java
7b5b6abf852c039983eded25ebe43a70fef5a4ab 15-Mar-2011 Romain Guy <romainguy@google.com> Fix rendering artifact in edge fades.
Bug #4092053

The problem always existed but was made visible by partial invalidation.
When saving a layer, the renderer would try to postpone glClear()
operations until the next drawing command. This however does not work
since the clip might have changed. The fix is rather simple and
simply gets rid of this "optimization" (that turned out to be
usless anyway given how View issues saveLayer() calls.)

This change also fixes an issue with gradients (color stops where
not properly computed when using a null stops array) and optimizes
display lists rendering (quickly rejects larger portions of the
tree to avoid executing unnecessary code.)

Change-Id: I0f5b5f6e1220d41a09cc2fa84c212b0b4afd9c46
/frameworks/base/core/java/android/view/HardwareCanvas.java
cabfcc1364eb7e4de0b15b3574fba45027b45cfc 08-Mar-2011 Romain Guy <romainguy@google.com> Add support for partial invalidates in WebView
Bug #3461349

This change also fixes two bugs that prevented partial invalidates
from working with other views. Both bugs were in our EGL implementation:
they were preventing the caller from comparing the current context/surface
with another context/surface. This was causing HardwareRenderer to always
redraw the entire screen.

Change-Id: I33e096b304d4a0b7e6c8f92930f71d2ece9bebf5
/frameworks/base/core/java/android/view/HardwareCanvas.java
7d7b5490a0b0763e831b31bc11f17d8159b5914a 25-Jan-2011 Romain Guy <romainguy@google.com> Enable partial invalidates when rendering with OpenGL.

Change-Id: Ie8be06c4776b815e8737753eb8003b4fd8936130
/frameworks/base/core/java/android/view/HardwareCanvas.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/HardwareCanvas.java
ada830f639591b99c3e40de22b07296c7932a33f 13-Jan-2011 Romain Guy <romainguy@google.com> Cleanup implementation of hardware layers.

The new implementation relies on OpenGLRenderer's existing layer
code instead of duplicating it. The new code is much cleaner, with
simpler and better APIs and allows tracking of drawn regions inside
layers. Region tracking is not yet enabled but this will be done
in a future CL.

Change-Id: Ie826121a2227de8252c77b992a61218defea5143
/frameworks/base/core/java/android/view/HardwareCanvas.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/HardwareCanvas.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/HardwareCanvas.java
b051e895ccb696604349c6c5efe7c4747e1d1ab6 29-Sep-2010 Romain Guy <romainguy@google.com> Add display lists caching.

Change-Id: Iac3a248a81ed8cb076a83ef9d186b8ebba685b4c
/frameworks/base/core/java/android/view/HardwareCanvas.java