CODEWITHSUNDEEP
androidc++opengl-esandroid-ndk
Adi Shavit
Adi Shavit

Reputation: 17275

Creating a Mapped/Direct OpenGL ES Texture on Android NDK

I am working on an Android NDK app that needs access to the pixels of an OpenGL ES 2.0 texture.

OpenGL extensions allow doing this as described e.g. here, here, and here.
All of these approaches require using the GraphicBuffer class which is not a part of the NDK (see e.g. here). Apparently, this requires accessing a private C++ Android API (from the AOSP-Android Open Source Project).

First, if I actually build and link with the AOSP repo, will my app run on the same Android devices as the "pure"-NDK version?
Can anyone provide (ref. to) detailed instruction for how to do this and the pros/cons of doing this?

Second, Android's "Graphics architecture" document states:

ANativeWindow

The public Surface class is implemented in the Java programming language. The equivalent in C/C++ is the ANativeWindow class, semi-exposed by the Android NDK. You can get the ANativeWindow from a Surface with the ANativeWindow_fromSurface() call. Just like its Java-language cousin, you can lock it, render in software, and unlock-and-post.

To create an EGL window surface from native code, you pass an instance of EGLNativeWindowType to eglCreateWindowSurface(). EGLNativeWindowType is just a synonym for ANativeWindow, so you can freely cast one to the other.

and according to this GraphicBuffer is a "simple wrapper" over ANativeWindowBuffer.

So the second question is: Is it possible to create an OpenGL texture compatible surface like GraphicBuffer by using only EGL and NDK functions (without requiring AOSP)? If so how?

Upvotes: 6

Views: 2120

Answers (1)

user1906
user1906

Reputation: 2340

Starting by your second question, I don't think there is. If you want to keep your code only on the native side, you have to use GraphicBuffers. It would be great to have functionality like this exposed (iOS has core video pixel buffers), but I doubt it will ever happen.

You don't really need to build AOSP to work with GraphicBuffers. Just get a few of the headers where the structures are defined and used them in your code. Then use dlopen() and dlsym() to get the pointers to the functions that you need, and use them. As your last link points out, check system/core/include/system/window.h and frameworks/native/include/ui/GraphicBuffer.h The mangled function names make the code a pain to write, but it works. There is a good usage example in Firefox sources.

Upvotes: 2

Related Questions