Mapped / Direct OpenGL ES Texture Creation on Android NDK
I am working on an Android NDK application that needs access to OpenGL ES 2.0 texture pixels.
OpenGL extensions allow you to do this as described, for example. here , here and here .
All of these approaches require the use of a class GraphicBuffer
that is not part of the NDK (see for example here ). Apparently this requires access to the private C ++ Android API (from the open source AOSP-Android project).
First, if I actually build and link to the AOSP repository, will my app run on the same Android devices as the "clean" version of -NDK?
Can anyone provide (see) detailed instructions on how to do this and the pros / cons of doing this?
Second, Android "Graphics Architecture" indicates:
ANativeWindow
The public Surface class is implemented in the Java programming language. The C / C ++ equivalent is the ANativeWindow class, semi-protected by the Android NDK. You can get ANativeWindow from Surface by calling ANativeWindow_fromSurface (). Like its Java cousin, you can lock it, render in software and unlock it, and after.
To create an EGL window surface from native code, you pass an EGLNativeWindowType instance to eglCreateWindowSurface (). EGLNativeWindowType is just a synonym for ANativeWindow so you can overlay freely.
and according to this GraphicBuffer
is a "simple wrapper" on top ANativeWindowBuffer
.
So the second question is, is it possible to create an OpenGL compliant surface such as GraphicBuffer
using only EGL and NDK functions (no need for AOSP)? If so, how?
source to share
Starting from the second question, I don't think there is. If you only want to keep the code on the native side, you should use GraphicBuffers. It would be great to have functionality like this vulnerability (iOS has basic video pixel buffers), but I doubt this will ever happen.
You don't need to create an AOSP to work with GraphicBuffers. Just get some headers where structures are defined and used in your code. Then use dlopen()
and dlsym()
to get pointers to the functions you want and use them. As your last link shows, check system/core/include/system/window.h
and frameworks/native/include/ui/GraphicBuffer.h
. The changed function names make the code sick to write, but it works. The Firefox sources have a good use case.
source to share