I'm trying to optimize my Android OpenGL ES 2.0 application, and I find myself being CPU bound.
After googling, I've found this, which suggest to use a thread for updating objects, and a thread for rendering. The reasoning as to why this would be worth the context switching overhead is that eglSwapBuffers() (which supposedly is called at the end of every drawFrame) block the CPU for 16 ms, 16 ms of processor time that could be used to calculate the next frame's state.
I implemented this, but saw little to no gain in frames. In fact, a scene which used to render in 60 fps now renders in 30. On the other hand, a scene with many entities that used to render in like, 20 fps now renders in 30, but this could be due to other optimizations I've done while refactoring into two threads. I have my threads setup in such a way that the render thread waits() until the update thread tells it to resume, after which the update thread waits(), until the render thread tells it to resume, after which it will sleep for 10ms.
After googling even more, is seems that eglSwapBuffers() is actually asynchronous on more modern phones (I'm targeting Android phones with Scorpion CPU's/Adreno 220 GPU's or better), so you really gain nothing by threading.
My question is, what is the general consensus of how OpenGL apps should be implemented on Android?
Should I do all my updating in GLSurfaceView's onDrawFrame (the way I used to have it), or should I split it into two threads (the way it is now)?
Another thing to consider is that I now make use of a double buffer strategy, which adds quite a lot of complexity to my code.
Please argue for which of these paths you'd think be the best choice for somewhat contemporary phones.
