4

For the development of a cross platform OpenGL game engine,

  1. Is there a performance advantage from using:

    • NativeActivity or android_native_app_glue

      over:

    • Defining an Activity, creating a GLSurfaceView, and setting the renderer to call native methods; implementing the JNI calls yourself?

  2. If using NativeActivity, are there any disadvantages: e.g. can you still use Google Play Game Services?

docjaq
  • 71
  • 5
  • 2
    Keep in mind that even a "native activity" is still heavily jni based - it just uses stock java code rather than custom code written by you. – Chris Stratton Sep 02 '14 at 15:41
  • Yeah, that's what I assumed, though I wasn't 100% sure. So realistically, I assume it's still doing a JNI call per frame, which is presumably the significant part of the overhead anyway? – docjaq Sep 02 '14 at 15:48
  • 1
    The JNI call overhead when calling into native code is measured in nanoseconds on modern devices. It's only significant if you're making a lot of them. Calling back into the VM from Java is much slower, but we're still talking about a few microseconds. I would, however, recommend avoiding GLSurfaceView and just using plain SurfaceView, as that will give you full control over the EGL context and threading. And if you want to do a game engine, you should first read through all of https://source.android.com/devices/graphics/architecture.html . – fadden Sep 03 '14 at 05:00
  • Ah, fair enough, and thanks for the link. When you say "Calling back into the VM from Java," do you mean "Calling back into the VM from native/c?" – docjaq Sep 03 '14 at 08:32

0 Answers0