summaryrefslogtreecommitdiff
path: root/core/java/android/view/GLES20TextureLayer.java
Commit message (Collapse)AuthorAgeFilesLines
* Refactor HardwareLayerJohn Reck2014-02-101-108/+0
| | | | | | | Defer all the things! Groundwork to allow hardware layers to work in a renderthread world Change-Id: Ib3aa47525f393083621254a743dbaa6352f933bd
* update to new Consumer APIsMathias Agopian2013-07-161-1/+1
| | | | Change-Id: I8649f3add40e0aeeeb0396b98e2cb93312e8e990
* Add an on-screen overdraw counterRomain Guy2013-05-031-0/+5
| | | | | | | | | The counter can be enabled by setting the system property called debug.hwui.overdraw to the string "count". If the string is set to "show", overdraw will be highlighted on screen instead of printing out a simple counter. Change-Id: I9a9c970d54bffab43138bbb7682f6c04bc2c40bd
* Don't destroy the same texture twiceRomain Guy2012-09-251-1/+1
| | | | | | | | | | | | | 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
* Update layers in a single batch at the beginning of a frameRomain Guy2012-09-211-1/+1
| | | | | | Bug #7186819 Change-Id: Ice5926dfedfb3be3a3064e65008dafa2852407da
* Fix occasional crash bug with layersChet Haase2012-09-171-1/+2
| | | | | | | | | | | | | | | | | | | | 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
* It seems that apparently useless public APIs are actually usefulRomain Guy2012-08-081-2/+3
| | | | | | Bug #6953651 Change-Id: Ic47ce504e63262711f5d3edc76f7d2b9c12471ad
* Cleanup of libhwuiRomain Guy2012-08-071-3/+2
| | | | Change-Id: Ib7f5771548462c00027a8ad57badfb68c50644f9
* Update layers' opaque property when neededRomain Guy2012-07-111-6/+5
| | | | | | | | 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
* TextureView: add setSurfaceTexture methodJamie Gennis2012-04-051-0/+14
| | | | | | | | | | | | | This change adds support for transferring control of a TextureView's SurfaceTexture between the UI framework and the application. It makes the TextureView detach the SurfaceTexture from the UI framework's GLES context before calling the surfaceTextureDestroyed callback, allowing the app to use the SurfaceTexture in its own GLES context if it so chooses. This change also adds the TextureView#setSurfaceTexture method, allowing an app have the TextureView use a SurfaceTexture that already exists rather than creating a new one. Change-Id: Iac9cc917687e4239dd1c24eae553709aa37512da
* Deferred layer updatesRomain Guy2012-03-021-0/+5
| | | | Change-Id: I83d9e564fe274db658dcee9e0cc5bbf9223ebb49
* Add an API to set the transform on a TextureView's surface texture.Romain Guy2011-08-161-0/+6
| | | | | | Bug #5156689 Change-Id: I635a625885c9b832a60d44ece0de7613ceb84109
* Code cleanupRomain Guy2011-06-241-0/+2
| | | | Change-Id: I64c346004e0adf9a776d0315534d4fe445f0c0ca
* Make TextureView to use async SurfaceTexture.Grace Kloba2011-06-231-1/+1
| | | | | | | | With this, there is no synchronous destroy SurfaceTexture requirement any more. Revert the previous change which only applies to the sync SurfaceTexture. Change-Id: Id4790d38a27f2982d0c8ad471bc1107683d27ffc
* Add the ability to specify the opacity of a TextureViewRomain Guy2011-06-221-4/+4
| | | | | | TextureView assumes its content is opaque by default. Change-Id: Iba873423566a5b67c388081838bd910dceba32ba
* Properly refcount SurfaceTexture in the JNI layer.Romain Guy2011-06-151-2/+2
| | | | Change-Id: I4b4c8020c13b8d6ce0d302fe42410033bf5785a6
* Allows to render with an OpenGL context inside a TextureView.Romain Guy2011-05-021-2/+2
| | | | Change-Id: I59453f7fc3997f0502a1c5d325d37fed376fabc7
* New widget: TextureViewRomain Guy2011-04-281-0/+76
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
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-26 02:52:10 +0000