reklis Wrote:The Oolong skeleton project simply rotates a multicolored cube in space. This should give us a nice "Apples to Apples" comparison of different event pumping mechanisms with unchanging rendering and FPS calculation code.

The length of time taken to run through the render code is often a factor. I think rendering a simple cube (so, 12 triangles assuming you're not culling the back faces) is NOT a good enough representation of what your average game will be doing..

reklis Wrote:Switching from NSTimer to a mainGameLoop does not appear to improve anything, and may actually hinder performance.

I think you'll find if you're rendering a more complex scene, or have some physics simulations happening in your application, it might change things a bit. Especially with a low timer period (i.e. 1/60), where you'll start to notice beat frequencies when the timer misfires. Even though your average FPS might look ok, timer misfires cause stuttering or jerkiness in the animation. I've seen this on many applications on the app store.

Is your 'main loop' in a separate thread? (I think it would need to be). What priority did you set on the thread?

What are the times you are showing on your 'main thread' results (0.001, 0.002, etc.) Sleep time per cycle? They seem a bit arbitrary. I'm not sure what a random sleep period gains you. If you're trying to go as fast as possible, why sleep at all? The iPhone hardware refresh is 60Hz, so you *could* run a tight loop (no sleep) and allow the blocking in the OpenGL swap buffers calls to keep your drawing in check at 60fps.