views:

466

answers:

1

I have an OpenGL ES 1.1 project on iPhone, based heavily on the empty OpenGL ES application given here:

http://iphonedevelopment.blogspot.com/2009/06/empty-opengl-es-application-project.html

I'm testing on a 3G (not 3GS) device, 8GB.

The paint loop in my app which does openGL operations is doing quite a lot each time it renders the screen. However, in situations with it doing the same thing each paint cycle, I'm seeing variable frame rates. I have set the NSTimer which fires the paint code to fire 30 times a second -- i.e. every 0.0333 of a second. The main problem is that whereas my actual paint code often takes approximately that amount of time to execute one paint (in terms of wall time), it varies, and sometimes it takes far longer, for no apparent reason. Using careful logging to report maximum time intervals when they occur, I can see that sometimes my paint has taken as long as 0.23 sec to complete - that's like 4FPS, which compared to 30FPS is like skipping 5 frames of animation/ user interaction, which isn't very acceptable.

At first I suspected my paint loop was snagging on some lock (there aren't many in there, because the GL render stuff in on the main thread (which is necessary AFAIK), as is incoming event handling) but some logging with finer granularity revealed that, in one paint code execution cycle, a large time elapsing over a bit of code that was doing basically hardly anything, and certainly not a GL operation.

So it seems a bit like my GL drawing thread (i.e. the main thread) just takes longer sometimes for no good reason. I have comms in my application and I disabled comms to see if that was the problem -- but I still see some "spikes" in execution time of my painting, when it's doing the same painting each time.

It's seems like another thread is just being switched to, mid-paint code, for ages, before returning to my paint code, on occaison.

Any ideas with how to analyse further what is going on? I know NSTimers aren't perfect and aren't at a guaranteed frequency, but the main issue here is that my actual paint cycle sometimes just takes forever, presumably because some other thread gets switched to....

A: 

Keep in mind that your application can seem to "hang" for no reason that has nothing to do with your "main loop". That's because you are multitasking... and in paticular, something as simple as your phone checking email can cause this sort of problem. One big cause, on the iPhone anyway, is when you move through different cell sites (like if you are on a subway or in a car) you can sometimes get spikes as it does... whatever it does.

If you are on an iPhone, try airplane mode and see if the problems go away.

-- David

David Whatley
Hi David, thanks for replying.We have indeed tried airplane mode, and with all comms disabled (we have a different thread launching sycnhronous comms requests via NSURLConnection, but only one request at a time). We still occaisonally get the 'spikes' (but not nearly as badly!)I think the strategy of not using NSTimer will help, which I'm going with.This is a very interesting set of slides about iPhone OpenGL performance, and it addresses the "NSTimer as paint loop timer" problem:http://www.slideshare.net/llopis/squeezing-every-drop-of-performance-out-of-the-iphone
lexh
The new DisplayLink functionality was added to specifically because of the phase problem with NSTimers and display refreshes. But its not going to cause big spikes (> 2x single frame time).
David Whatley