For packages:
javax.microedition.khronos.opengles
javax.microedition.khronos.egl
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I3615f60789c14c44284c896c3a9ea291100dff8e
For packages:
android.opengl
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I747cf5d5e6e211dc368545472fee65fd20cdae74
Fixes: 34512969
Test: manual, tested repro in bug and verified
basic GLSurfaceView usage in ApiDemos works
without warnings
Change-Id: I0ce9128874af681e9cfbd3b0b2ef5e2df7080154
SurfaceView needs to notify the window manager that
drawing has been completed, so that animations and such
can begin. Currently this is implemented through
having the SurfaceView user block in surfaceRedrawNeeded
(called from UI thread) until a frame has been completed.
This blocking can be unnecessary serialization during startup, and
also clumsy to implement for some users.
Test: GLSurfaceView and takeSurface API Demos, android.server.cts.SurfaceViewTests
Bug: 31850030
Change-Id: Idda02098a635f25cf392f2d59a3abbe54a1d64d4
This function was never properly supported. It had partial support in our JNI
layer in EGL10 but not implementation in EGL14. It has never been tested and
it is unlikely that drivers support pixmap rendering.
Bug: 11257511
Test: CtsGraphicsTestCases
Change-Id: I209fff470c715cd97148a32b2f41ecf7e5283bab
Fixes: 27071678
It's semi-common for apps to not realize surfaceRedrawNeeded
is a callback they can (and should) be handling, so have it be
more tolerant in lifecycle handling.
Specifically allow a renderer to have not yet been set on
GLSurfaceView, even though it was supposed to have been set already.
Apps are overriding the other lifecycle methods that require this
(created, changed, an destroyed) but not noticing this method.
Change-Id: I6cebca541eeec6e9949bdb55f687b095768a17b2
- For reading into PBOs on GLES3, add an overloaded version of
glReadPixels that takes an offset argument.
Bug 18878609
Change-Id: I744483deab6358a66b0dc5e87be1ae2b96560ac1
- Deprecate the broken version that takes a byte argument.
- Implement a new version that takes a byte buffer argument.
Bug 19478262
Change-Id: I5ea4f11940e93b5964b66dbf5700b7ff8b80339e
It is possible for clients to call SurfaceView
methods e.g. setFormat from the GLSurfaceView#Renderer
drawFrame callback. In this case, SurfaceView#updatewindow
will understand that a redraw is required, and will request
it back to GLSurfaceView. Remember, we are still on the GLThread
though (from the drawFrame callback). So these methods
(requestRenderAndWait, windowSizeChanged), need to be reentrant.
Also fix a data race around mWantRenderNotification, which was
accessed out of lock.
Bug: 26770615
Change-Id: Ic66a36c886ae0b085dd456a4220f0d4f270fb016
GLSurfaceView was not supporting the surfaceRedrawNeeded protocol
which leads to issues with report draw. Thus far this has mostly
been fine as the main surface will not render
a transparent hole until the SurfaceView has finished drawing. However
in the case of SurfaceView replacement the hole in the parent surface
will be preexisting and we must be able to tell that our new SurfaceView
has actually drawn before removing the replacee. This is part of a
series of fixes to 26070641.
Bug: 26070641
Change-Id: Iecc16647f9979aa057449e8bafa540885881ed64
GLTrace is defunct, it does not support newer GL features, breaks
security requirements, and has no supported tooling now that Eclipse
is at end of life.
Bug 22329852
Change-Id: I64c58464f8c2c7ae6125f5d5c7884e3fd34d68ea
Fix a bunch of places where mNativeBitmap was being
poked at directly, switch them either to the NDK API
or to GraphicsJNI where it made sense
Change-Id: I6b3df3712d6497cba828c2d3012e725cb4ebb64d
Bug: 17578553
Games seem to be doing this to prevent destruction of their
GL contexts, and they assume it works even if it doesn't. However,
GLSurfaceView is clunky here, so while the app is doing something
questionable we don't really offer a better way. For now revert
back to kitkat behavior.
Change-Id: Icfa9e496279b9cfa47f9bc7f6848d9313caed0d5
OpenGL ES have 3 configuration: 1(EGL10.EGL_RENDERABLE_TYPE),
2(EGL_OPENGL_ES2_BIT), 3(EGL_OPENGL_ES3_BIT_KHR). The driver
should be get the according configuration parameter.
Now 1 is set to driver when Configuration 3 is set from user.
Specification EGL_OPENGL_ES3_BIT_KHR is set to driver when a OpenGL
ES 3 context is requested in setEGLContextClientVersion().
Change-Id: I980d9d8dbe5754295f8329fcf9378962d669fa89
Signed-off-by: Jin Zhebin <zhebinx.jin@intel.com>
Signed-off-by: bdeng3X <bingx.deng@intel.com>
Requested by jreck to fix the build.
This reverts commit 198d20842a537f3df3584ea084e74220e172b086.
Change-Id: I733065cc124b59bf914034f5bac5e2e951a5b604
Bug: 13338698
Move the releasing of hardware resources to a new
@hide onDetachedFromWindowInternal
Change-Id: I52b4e6ba4d5b3ce20b89cabffa248d1d780e3e81
EGLObjectHandle.<init>(int) and int EGLObjectHandle.getHandle()
have now been deprecated and replaced with variants that take
and return java longs.
bug: 13181704
Change-Id: I67bef5fbf064e85205b8a85e00f91f4ffcf60d19
Note that files changed in this patch have been automatically
generated by running frameworks/native/opengl/tools/glgen/gen
script
This will allow eglGetDisplay(int) to work on both 32-bit and
64-bit systems when EGL_DEFAULT_DISPLAY is passed as a parameter.
Change-Id: Idf27d6e00d623d331bb2d4d7f85fa450e0db26c9
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Note that files changed in this patch have been automatically
generated by running frameworks/native/opengl/tools/glgen/gen script
This patch updates EGL classes in frameworks/base to support
64-bit platforms. Key changes in the EGL classes include
[x] EGLObjectHandle class - EGLObjectHandle class has two public
methods (constructor and getHandle) that assume handles are
32-bit. They have not been changed. Instead, two new hidden
methods (EGLObjectHandle(long) and getNativeHandle) have been
added.
[x] EG14 class - Two public methods eglGetDisplay and
eglCreatePbufferFromClientBuffer assume that handles are 32-bit.
They have been changed to throw unsupported operation exception
on non 32-bit machines. Two new methods eglGetDisplay(long)
and eglCreatePbufferFromClientBuffer(...long buffer..) have
been added to support 64-bit handles.
Change-Id: I9e0f064e5b33700eb0baa2e1841a21f931f7a765
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
They were replaced with correct bindings a while back, but the
broken methods weren't hidden.
Bug 6006380
Change-Id: I3432d37a6bf411bbd2b3ea363749e32fcff28672
