Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 06 May 2012
Offline Last Active May 06 2012 05:26 PM

#4937899 Android + OpenGL ES...double buffered? threaded? gameloop?

Posted by mame82 on 06 May 2012 - 05:22 PM

1) OpenGL ES isn't double buffered by default, but GLSurfaceView uses double buffering in your configutration (eglSwapBuffer is called automatically). you can change this behaviour if you call setRenderMode(RENDERMODE_WHEN_DIRTY), now you can force swapbuffer yourself by calling requestRender() (Look at GLSurfaceView on the reference page)

Tripple Buffering is also possible, look for the video about OpenGL developing from the last google IO. The guy explains how to use triple buffering for benchmarking purposes (with double buffering most devices have a fixed output of 30 / 60 fps)

2) The renderer is indeed on its own thread, GLSurfaceView starts the Thread after setRenderer() get's called. I've rewritten this class for Wallpaper-rendering with OpenGL ES 2.0 and took a deeper look. GLSurfaceView does all the EGL things with the more complicated android stuff for your, handling the RenderThread, Managnig the EGLContext (important because of the different behaviours on different devices, when other activities need a lock on the EGLContext - not trivial to manage this on your own)

3) I've choosen the way to build up two extra Threads for my current developments (one for logic, one for animations, several others are launched by android like SensorThread for polling accelerometer). In general I could say these things:
- don't do heavy work on androids UIThread, which isn't the case if you do it in onDrawFram() because now its done by the renderThread
- if you do heavy work like IO-operations use a ASyncTask
- its hard to implement extra threads in the java manner (new Thread and calling run() ) because you have to take care of the whole synchronizing and more care on
bringing your Threads to idle-state if your activity is paused (or you app is a battery drainer). This isn't the preferable way as long as you haven't performance problems while using the render-thread

Avoid using native code, except you have to (ready c / c++ implemantations) - the dalvik vm is really fast, especially since it uses a JIT-Compiler (since API-Level 8 I think).
You still have to call your c/c++ written wrapper methods through JAVA (with JNI / NDK), nothing else the Android-API is doing So you don't have a performance increase, except your logic is handled here and you make use of special ARM CPU features like the NEON-platform or similar things

Look a christmas 3D on android market, if your device can handle it you'll see 2 things
first: all resource are loaded in the render-thread, not with a async task (very long load time, user can't see anything)
second: camera handling, matrix operations, particle calculation are also handled in the render task, but with less performance penalty than thread handling -->
the need of an extra thread depends on what logic work you have to do