| ef09a210dd6ea481158b7028ec2424a7f5769ed2 |
|
25-Sep-2012 |
Romain Guy <romainguy@google.com> |
Don't destroy the same texture twice
Bug #7221449
SurfaceTexture already deletes the GL texture when detachFromContext
is invoked. The newly introduced refcount would casue the Layer
object to be destroyed later and attempt to delete the GL texture
again. By the time the second cleanup occurs, the texture name
might have been reused by somebody else, resulting in erroneous
behaviors.
Change-Id: I257c589fea64b34c00f46fbfaa7732e6854a5e41
/frameworks/base/core/java/android/view/HardwareLayer.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/HardwareLayer.java
|
| 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/core/java/android/view/HardwareLayer.java
|
| d15ebf25c595b855f6978d0600218e3ea5f31e92 |
|
05-Sep-2012 |
Chet Haase <chet@google.com> |
Enable changing properties of layer paint
Previously, to draw a layered view with a changed Paint object for the
drawLayer operation, you'd have to invalidate the parent view, to get the
native DisplayList to pick up the new Paint properties. This change adds
API and functionality so that the developer can call setLayerPaint(), which
does the proper invalidation (lightweight, doesn't cause redrawing the view).
Issue #6923810 Make it easy to efficiently animate a layer's Paint
Change-Id: I7fea79788d50f6d9c86dd5e5b2a4490cb95142bb
/frameworks/base/core/java/android/view/HardwareLayer.java
|
| c89b14bba0f6cc2c91629080617f7ed215f697f3 |
|
08-Aug-2012 |
Romain Guy <romainguy@google.com> |
It seems that apparently useless public APIs are actually useful
Bug #6953651
Change-Id: Ic47ce504e63262711f5d3edc76f7d2b9c12471ad
/frameworks/base/core/java/android/view/HardwareLayer.java
|
| 17112ad8a21a77620eb1ff14dcf8bdd6b7859712 |
|
07-Aug-2012 |
Romain Guy <romainguy@google.com> |
Cleanup of libhwui
Change-Id: Ib7f5771548462c00027a8ad57badfb68c50644f9
/frameworks/base/core/java/android/view/HardwareLayer.java
|
| f0af1d5cb255f136d2fff773be7518ffd7ae3b93 |
|
12-Jul-2012 |
Romain Guy <romainguy@google.com> |
Remove unused View.flushLayer() API
Change-Id: I5d4c7388afb5265964ab6b769cc0abfee9745c84
/frameworks/base/core/java/android/view/HardwareLayer.java
|
| 846a533945576e5cb1a66529ca3a52d71749f04f |
|
12-Jul-2012 |
Romain Guy <romainguy@google.com> |
Update layers' opaque property when needed
Before this change, changing a View's opacity would not be reflected
by hardware layers. This could cause layers to retain their previous
opacity.
Change-Id: Iba2c8b4242deca021651df9324cc7c585a64653d
/frameworks/base/core/java/android/view/HardwareLayer.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/HardwareLayer.java
|
| 7e52caf6db5feef2b847cfaa3d13690257122c3a |
|
07-Mar-2012 |
Michael Jurka <mikejurka@google.com> |
Don't draw layers in buildLayer()
Creating the layer, if necessary, takes the bulk
of the time - just do the creation, and schedule a
deferred update
Change-Id: I21399ebd5d2929a4f242ec1c08e3f97fed1ef58a
/frameworks/base/core/java/android/view/HardwareLayer.java
|
| 2bf68f063b0077ddef6ebfe54f2ae5e063c2c229 |
|
02-Mar-2012 |
Romain Guy <romainguy@google.com> |
Deferred layer updates
Change-Id: I83d9e564fe274db658dcee9e0cc5bbf9223ebb49
/frameworks/base/core/java/android/view/HardwareLayer.java
|
| 9c4b79af221b53f602f946faa9ff317a596a0c39 |
|
11-Nov-2011 |
Romain Guy <romainguy@google.com> |
Discard framebuffer rendering queues when discarding layers
Bug #5581817
Change-Id: Ie30700a29059d2ea60eb7bd3f8bd20ac48a149ab
/frameworks/base/core/java/android/view/HardwareLayer.java
|
| 7077506f9945b87b02bdd47ffce75a5b813c821c |
|
14-Nov-2011 |
Dave Burke <daveburke@google.com> |
Revert "Discard framebuffer rendering queues when discarding layers"
This reverts commit da96f8ac2c1c35a54f3f36e6d776cb386a251d03.
/frameworks/base/core/java/android/view/HardwareLayer.java
|
| da96f8ac2c1c35a54f3f36e6d776cb386a251d03 |
|
11-Nov-2011 |
Romain Guy <romainguy@google.com> |
Discard framebuffer rendering queues when discarding layers
Bug #5581817
Change-Id: If612846ec5f7793710fc4df152791fb32c506551
/frameworks/base/core/java/android/view/HardwareLayer.java
|
| 302a9df1d50373c82923bb84ff665dfce584fb22 |
|
16-Aug-2011 |
Romain Guy <romainguy@google.com> |
Add an API to set the transform on a TextureView's surface texture.
Bug #5156689
Change-Id: I635a625885c9b832a60d44ece0de7613ceb84109
/frameworks/base/core/java/android/view/HardwareLayer.java
|
| 02ccac69fd1c0a03c24c5f3ace0ad4bed337b1fd |
|
24-Jun-2011 |
Romain Guy <romainguy@google.com> |
Code cleanup
Change-Id: I64c346004e0adf9a776d0315534d4fe445f0c0ca
/frameworks/base/core/java/android/view/HardwareLayer.java
|
| aa6c24c21c727a196451332448d4e3b11a80be69 |
|
29-Apr-2011 |
Romain Guy <romainguy@google.com> |
New widget: TextureView
Bug #4343984
TextureView can be used to render media content (video, OpenGL,
RenderScript) inside a View.
The key difference with SurfaceView is that TextureView does
not create a new Surface. This gives the ability to seamlessly
transform, animate, fade, etc. a TextureView, which was hard
if not impossible to do with a SurfaceView.
A TextureView also interacts perfectly with ScrollView,
ListView, etc. It allows application to embed media content
in a much more flexible way than before.
For instance, to render the camera preview at 50% opacity,
all you need to do is the following:
mTextureView.setAlpha(0.5f);
Camera c = Camera.open();
c.setPreviewTexture(mTextureView.getSurfaceTexture());
c.startPreview();
TextureView uses a SurfaceTexture to get the job done. More
APIs are required to make it easy to create OpenGL contexts
for a TextureView. It can currently be done with a bit of
JNI code.
Change-Id: Iaa7953097ab5beb8437bcbbfa03b2df5b7f80cd7
/frameworks/base/core/java/android/view/HardwareLayer.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/HardwareLayer.java
|