Best practice for OpenGL ES 2.0 rendering on Android

Question

With the languages and libraries I've worked so far, there was always an option to sync the main loop of the program (a game or anything with an always changing context) to the current display's refresh rate. So I had the option to either switch on VSYNC or just let the loop execute as many times per second as it could. I'm referring to SDL2, OpenGL 3.0 with GLFW, the HTML5 canvas etc.

I'm looking for something similar on Android now in OpenGL ES 2.0, but so far all the example code I can find simply uses a variation of sleep and set the framerate to 60 or 30. So they basically count the amount of time passed since the last iteration, and only advance further and call the requestRender() function if a given amount of time has passed (0.016 ms in case of 60 frames per second etc.).

I'm simply wondering if there's a better option than this or not. I'm just concerned that not every phone has the same screen refresh rate, so hard coding any amount doesn't seem to be a desired method. As far as I understand it is not that simple to figure out the given phone's refresh rate, or at least it is not possible with "pure" Java and OpenGL.

Answer 1

What you need to do is match the display's frame rate, and advance game state according to how much time has elapsed since the previous frame. There are two ways to go about this:

1. Stuff the BufferQueue full and rely on the "swap buffers" back-pressure.

   This is very easy to implement: just swap buffers as fast as you can. In early versions of Android this could actually result in a penalty where SurfaceView#lockCanvas() would put you to sleep for 100ms. Now it's paced by the BufferQueue, and the BufferQueue is emptied as quickly as SurfaceFlinger is able.

2. Use Choreographer.

   Choreographer allows you to set a callback that fires on the next VSYNC. The actual VSYNC time is passed in as an argument. So even if your app doesn't wake up right away, you still have an accurate picture of when the display refresh period began. Using this value, rather than the current time, yields a consistent time source for your game state update logic.

source: https://source.android.com/devices/graphics/arch-gameloops