views:

26

answers:

1

I have a project where it rotates 2 spindles 360 degrees both at different speeds over time. I have noticed that it runs well on simulator but when I test it on a device it is significantly slower. The timing taken to make the first 3 full rotations on the simulator and the device are:

On Simulator: 7.0, 7.2, 7.2

On Device: 19.3, 19.5, 19.7

Essentially the project works but I'd like to find out why there is such a big difference between device and simulator and I thought CGContextRotateCTM might be the source.

+1  A: 

Sounds right.

Don't forget, when you run the simulator, you are actually compiling native code to run on your native x86 hardware. Assuming your Mac runs faster than the 800MHz ARM chip in the iPhone - no surprise it will run faster in the simulator.

If you need deterministic timing in your application, your going to need more work to achieve that. This is where people use things like the UIView animation timing, NSTimer calls, or cocos2d inter-frame timers to give deterministic time to their animation calls.

If you don't - when the next gen device comes out with a faster CPU - your app will again be messed up.

Remember when they used to have "Turbo" buttons on PCs to deal with this?! :-O

Brad
Thanks Brad, that has confirmed what I thought might be the problem as well. Do you have any particular examples that shows deterministic timing? I do remember my IBM 386 having the Turbo button hah!
Azeworai
You could implement this functionality like in cocos2d by calling "setNeedsDisplay" of your UIView at the end of the "drawRect" - while *keeping track* of the absolute time of the *last* drawRect - thus you would be able to see how fast you are updating - just like in Cocos2d. This would make it so the event loop would keep sending you redraw events - which you could act on - while taking the difference between the *current* and *last* drawRect times to determine how far your "animation" should "move".
Brad