# Android game loop's effect on cpu/battery usage - unexpected results

I will try to keep this question as concise and as readable as I can.

I recently came across an odd problem with my Android game that I'm developing.

It's an openGL ES 2.0 game and initially I was using RENDERMODE_CONTINUOUSLY, my gameloop was running on the OpenGL provided rendering thread and I was basically limiting the logic updates (to say, 30 times per second), while letting the rendering run as fast as the device could handle.

Everything works well, but when I ran the game on an old Galaxy Ace phone it was rendering at 85+ Frames Per Second which got me thinking that it could be using more battery than it needed to (because it was rendering frames which didn't need to be rendered as there were no logic updates in-between them).

I set RENDERMODE_WHEN_DIRTY, started another thread myself, put my game loop into that thread and from this loop, called update() (For logic updates) and requestRender() (for drawing). I altered the gameloop so that it would only render when there was an update.

Now, the way it stands, If I limit my loop to say, 30 ticks per seconds, then all is good, both rendering and logic run at a smooth 30 tics per seconds. If things get too much and the device can't handle the rendering, and the frame rate drops (lets say, to 12FPS), then the logic will carry on at 30 times per second which is exactly what I'm after.

Howevever, I've used the CPU Meter in Jellybean and it would appear that the first option (2 threads, rendering flat out) is more CPU (and therefore, I assume battery) efficient that the 2nd method (3 threads, but with rendering limited).

I'm trying to figure out why this would be?

Please note that I can't test the CPU usage on the Galaxy Ace phone as it doesn't run jelly bean, but certainly on my Nexus 10 tablet, the CPU usage is more when using the 3 threaded approach.

I understand that now, my loop still 'loops', even when it has no updates or rendering to do (never sleeping), but this was the case in the first loop too (well, when it had no updates, it would carry on rendering regardless).

So what gives here?

Note: I haven't posted code as it's not really relevant to the question. But if you want to see the loop, please ask and I will post - thanks

With OpenGL, am I best to just leave the device to render as fast as it can? That certainly seems to be the way it's been set up (at least when using RENDERMODE_CONTINUOUSLY)

• Maybe your render loop was actually "sleeping" - that is, waiting for render to happen, which tasked GPU but not CPU? Are CPU and GPU even different on Android devices? – Nevermind May 8 '13 at 14:05
• Hi @Nevermind I don't think the loop was ever sleeping that I know of. (If it was, what would be controling that? And why would the phone be rendering at 85-90 fps?) Yes CPU and GPU are different. – BungleBonce May 8 '13 at 14:14
• It looks like you may have no choice but to sleep on portable devices – bobobobo May 9 '13 at 1:58
• eglSwapBuffers blocks for the remainder of the frame (waiting for VSYNC). This is good, but as soon as you split into 2 threads (update/draw) it appears you are SOL on slowing down the update thread without calling sleep. – bobobobo May 9 '13 at 2:07
• That's a shame, the Nexus 10 tablet's vsync is limited to 60fps but an old Galaxy Ace phone just render away to it's heart's content, sometimes at +100 FPS! – BungleBonce May 11 '13 at 21:12

Maybe the (presumably trivial) activity of the third thread is being exaggerated in the accounting? You can get a simple per-thread breakdown with adb shell ps -x -t; the "u" number indicates time spent in user-space, the "s" number is time spent in the kernel.