1

Is there a simple way to test if there is a current context within the Android NDK ?

If an EGL context is bound on the java-side of the jni boundary is the binding valid on the native side of the jni boundary? How about vice-versa? If the binding works bi-directionally can I issue GL commands as I see fit on either side of the boundary without additional logic required ?

Pointers to example code w/ context setup on both sides of the boundary appreciated. Not sure how the surface / EGL interaction would look on the JNI side.

Thanks.

user501138
  • 869
  • 2
  • 9
  • 16

1 Answers1

2

To check if there's a current context in native code, you can call eglGetCurrentContext():

if (eglGetCurrentContext() != EGL_NO_CONTEXT) {
    // There is a current context.
}

Yes, contexts remain current across the JNI boundary. So if you have a current context in your Java code (e.g. managed by GLSurfaceView), you can make JNI calls, and then make OpenGL calls in the implementation of the native function, without any special consideration. I answered a question related to this in more detail here: FrameBuffers with GLSurfaceView pattern in OpenGLES 1.1 on android ndk.

There's no good reason why the opposite wouldn't be true. You should be able to create a context in native code, make it current, and it should still be current in your Java code after the JNI call returns. It seems much less useful, but if you have a good reason to do this, nothing should stop you.

If you really do want to create contexts in native code, I posted a complete example of how to do that in an answer here: GLES10.glGetIntegerv returns 0 in Lollipop only.

IMHO, by far the easiest way to use native code with OpenGL calls is to use a GLSurfaceView, let it handle the whole context creation and management, and make JNI calls in the implementation of the Renderer. Then in the native code, you simply make your OpenGL calls, without worrying about context management.

Community
  • 1
  • 1
Reto Koradi
  • 53,228
  • 8
  • 93
  • 133