EGL classes in frameworks/base have to be updated 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.
To allow the above changes in frameworks/base EGL classes,
corresponding code generation mechanism in frameworks/native has
been updated.
Change-Id: I5d0a62e10c20ccf05f610d6608b8dfb6414b5116
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Patch from synergydev with commit-id 01994c79 changed
core/jni/com_google_android_gles_jni_GLImpl.cpp in the
frameworks/base. However the corresponding code snippet
in frameworks/native was not updated. This patch addresses
the issue.
Change-Id: I89c3d88de832efc8cbbe682c8a7ff7dfbef99db3
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Patch from Takeshi Aimi with commit-id f9337377 changed
core/jni/android_opengl_EGL14.cpp in the frameworks/base.
However the corresponding code snippet in frameworks/
native was not updated. This patch addresses the issue.
Change-Id: I40bcc43d36d7ab4e0db4a73556a4f7480c7431c1
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
this means they only have access to the consumer end of
the interface. we had a lot of code that assumed consumers
where holding a BufferQueue (i.e.: both ends), so most of
this change is untangling in fix that
Bug: 9265647
Change-Id: Ic2e2596ee14c7535f51bf26d9a897a0fc036d22c
Make it faster and correcter.
Also, fixed the "gen" script to update the static/egl/*.java files
as part of doing an update. Altered the "git" lines to change
directories before invoking git -- necessary because we're now
split between frameworks/base and frameworks/native.
Bug 9204146
Change-Id: Ie60504b1932349e6f2c9d3868dee6a645ef2b36e
Initially populated with EGL_ANDROID_presentation_time (moved from the
EGL14 class) and the ES-relevant parts of EGL_KHR_create_context.
Bug: 8678160
Change-Id: Ifed2ee3da264ca701ae1f4b309a0758f7fcc3acc
The getarray() function checks to see if there's enough room in
the buffer, but it's using a byte count for the available size
and a possibly non-byte count for the space required. Dividing
down by the unit size corrects the problem.
Bug 8713753
Change-Id: Id42c0df65c3233dcc5f76d05e229f7d40d4c1f99
Updating the generator to handle GLvoid*/java.nio.Buffer return values
probably wouldn't be too hard, but this is the only function that
needs it currently.
Bug: 8566953
Change-Id: I359a951136ab479ab576ce2e5a2881b937b7e8c9
Just a search-and-replace on the glGetActiveAttrib special-case, since
they have the same signature and parameter handling.
Bug: 8566953
Change-Id: I40834d6f32bf9ecb39718df29036aa2d1bbfa07a
Some of these are new ES3 functions, some are existing ES2 functions
that can now use the new pixel pack/unpack buffer bindings.
glDrawElementsInstanced needs a special case since the pointer/offset
arg isn't the last one like the generator assumes.
Bug: 8566953
Change-Id: I638a36b0a31aefcb5bfee6f4d049348223045103
Return values are declared with the C return type, but the JNI
function returns the JNI return type. In the case of GLsync/jlong as
in glFenceSync(), this causes a compile error. So the generator now
explicitly casts the return value to the JNI return type.
Bug: 8566953
Change-Id: I814befe2e4cce745434cbc4e1c8639fc3ce8aeae
This change adds ES3 functions to GLES30.spec, disabling any that
require non-trivial changes for the generator to handle.
Steps taken to add these:
- Copy ES3 function declarations from gl3.h
- Remove GL_APICALL, GL_APIENTRY, and semicolon from each declaration
- Add whitespace around parens and *s as required by the parser
- Comment out functions that the generator doesn't understand or that
it generates bad Java interfaces for (by inspection).
Bug: 8566953
Change-Id: Iaaef7d53e24f9a576759dbba72cd206bae1c1276
With the addition of float framebuffer support in ES3, some parameters
to ES2 functions are now GLfloat instead of GLclampf. Both are
typedefs for 'float', so this is a source and binary compatible change.
Bug: 8566953
Change-Id: I0b5acc78da7799a04053fdb568205f793792cad9
Added EGL extension to set a timestamp on a surface.
Also, fix JNI encoding of "long" in glgen.
Bug 8191230
Change-Id: I38b7334bade3f8ff02bffe600bb74469ef22c164
- added support for comments in checks.spec
- added most missing checks
- added and commented with // special-cased functions
- added and commented with # functions that are still missing validation checks
- moved glGet* to a special case and updated all the "pnames" from the khronos spec
- changed ifcheck to default to 1 value. this allows us to simplify the checks.spec file
and handle unknown pnames automatically (they'll be validated against 1 value, if
it happens to need more, the call will go through but the validation will not
happen).
- refactored the cpp headers in to a common header + GLES version specific
header
Bug: 7402895
Change-Id: Ib5c68ca0ca416407b4cfa36e3a21901b2d6263ab
- it looks like UserId has been renamed to UserHandle in the
framework.
- also for some reason I don't understand glgen didn't seem
to be up to date with respect to the generated bindings in the tree.
It's like the bindings were generated with a more recent version of
glgen (maybe it was never checked in). So we fix that here.
Change-Id: Ie49522ebf67fcab9213246b4d93500e37a3cbc05
The C++ class names don't match what the classes do, so rename
ISurfaceTexture to IGraphicBufferProducer, and SurfaceTexture to
GLConsumer.
Bug 7736700
Change-Id: Ia03e468888025b5cae3c0ee1995434515dbea387
This fixes the glgen code generation for methods
which have a buffer arg that can be NULL.
Bug: 6845189
Change-Id: I5fb745b806601e5665f97bfd15fd865cd9c241ed
this adds correct versions of the broken GLES20 methods
glGetShaderSource, glGetActiveAttrib and glGetActiveUniform.
the old broken methods are still there and need to be @hide later.
Bug: 6006380
Change-Id: Ide74242ada54b85459b459ae4f20cd26a23c7610
This changes generation of the OpenGL bindings to prevent
crashes of methods with more then one nio buffer argument.
Bug: 6772416
Change-Id: I4eff25c2f568dea78a6ffd3e95ff4620ab4b3b7d
This change adds Java definitions for the enums of the
GL_OES_EGL_image_external OpenGL ES extension.
Bug: 3482193
Change-Id: Ib50326f8be9b9cc9021753855c3846ddcdc5eaa2
Just use jniThrowException instead. Note that it would be trivial to throw
seemingly more appropriate exceptions (NullPointerException and
OutOfMemoryException in particular), but I'm only attempting to preserve
existing behavior here.
I also found shadowing bugs in some of the special-case functions, which
would previously always have leaked memory.
This also moves an accidental change to a generated file (ActivityThread ->
AppGlobals) into the generator, so it won't be overwritten in future.
Change-Id: Iab570310b568cb406c60dd0e2b8211f8a36ae590
