NSTimer fine, CADisplayLink having some issues
In a new project I started with the OpenGL ES template which checks the device's OS and uses CADisplayLink if it's available, or NSTimer if it's not.
All was working fine until I turned on accelerometer input. With the accelerometer sending input NSTimer still works exactly the same and is very smooth. But when using CADisplayLink with an animation timer of 1 (should be trying to fire 60 times a second) I get long pauses where no input seems to work (touch based or accelerometer), then the input will be received and the frame rate is just fine for a second and then another pause.
If I set the animation timer to 2 it updates consistently, but at 30 times a second and is noticeably less smooth than using NSTimer.
I can post code later (not at my laptop at the moment) but I was wondering if this is something anyone else has encountered?
I don't really have a problem with just sticking to NSTimer, but since CADisplayLink is Apple's preferred method moving forward I'd prefer to use it when available.
Thanks!
All was working fine until I turned on accelerometer input. With the accelerometer sending input NSTimer still works exactly the same and is very smooth. But when using CADisplayLink with an animation timer of 1 (should be trying to fire 60 times a second) I get long pauses where no input seems to work (touch based or accelerometer), then the input will be received and the frame rate is just fine for a second and then another pause.
If I set the animation timer to 2 it updates consistently, but at 30 times a second and is noticeably less smooth than using NSTimer.
I can post code later (not at my laptop at the moment) but I was wondering if this is something anyone else has encountered?
I don't really have a problem with just sticking to NSTimer, but since CADisplayLink is Apple's preferred method moving forward I'd prefer to use it when available.
Thanks!
Just guessing here, but on the Mac the display link fires on another thread. I forgot if that's the same on the iPhone, but I assume it is. I think the accelerometer input shows up on the main thread. Not sure if that's what the real problem is in your case, but that's the first thing that came to mind.
Hmmm... interesting! I must admit I'm not very up on multi threading since I've never really had to deal with it before. I'll do some Googling with threading in mind in relation to CADisplayLink and the accelerometer and see if I find anything.
This bug has shown up since 2.x of the iPhone OS. Basically the OS starts caching events on you when you are consuming too much CPU time. It's extremely frustrating and shows up (inconsistently) whether you are using a self pumped event loop, NSTimers or CADisplayLinks. I've seen this happen in dozens of games I've played too. Increasing the thread sleep time is the only way I've been able to avoid it.
Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
(Aug 20, 2010 07:10 AM)Skorche Wrote: This bug has shown up since 2.x of the iPhone OS. Basically the OS starts caching events on you when you are consuming too much CPU time. It's extremely frustrating and shows up (inconsistently) whether you are using a self pumped event loop, NSTimers or CADisplayLinks. I've seen this happen in dozens of games I've played too. Increasing the thread sleep time is the only way I've been able to avoid it.
Interesting. I wonder if adding something like the following into the main loop will help?
Code:
while(CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.002, TRUE) == kCFRunLoopRunHandledSource);I remember reading about this line being used to clear the event queue (source)
EDIT: Adding this line to my main loop crashes my game on iPad
No, that was what I used to do before CADisplayLink came around, and I've done it on OSX without the event queue getting clogged up. It's completely broken when compiling against the 4.0 SDK IIRC.
The really frustrating thing was that it worked differently in 2.x and 3.x. I needed to use a different delay value (your 0.002) depending on the OS version. Setting it to 0 caused severe event clogs, but the different OS versions needed different delay values to avoid it. While it was pretty hackish, using NSTimers made the framerate even less stable.
The really frustrating thing was that it worked differently in 2.x and 3.x. I needed to use a different delay value (your 0.002) depending on the OS version. Setting it to 0 caused severe event clogs, but the different OS versions needed different delay values to avoid it. While it was pretty hackish, using NSTimers made the framerate even less stable.
Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Possibly Related Threads...
| Thread: | Author | Replies: | Views: | Last Post | |
| iOS 6 fine, iOS 5, aspect ratio messed up | Madrayken | 0 | 828 |
Jan 7, 2013 11:50 AM Last Post: Madrayken |
|
| Updated to SDK4, CADisplayLink layer now sized wrong on iPad | michaeltoy | 6 | 3,809 |
Jul 19, 2010 12:39 AM Last Post: Madrayken |
|
| Alternative to NSTimer | demonpants | 78 | 37,525 |
Jan 11, 2010 01:52 PM Last Post: riruilo |
|
| NSTimer hiccups/choppy/jerky | jeonghyunhan | 2 | 2,409 |
Sep 24, 2009 07:35 PM Last Post: jeonghyunhan |
|
| Using an NSTimer to progressively draw a view | StevenD | 4 | 3,699 |
May 14, 2009 07:57 AM Last Post: StevenD |
|

