NSRunLoops and NSTimers

Howdy,
I have a couple of question and I was wondering if any of you could help answer them for me. First, I was looking at some of NeHe's openGL demos, ported for cocoa, and I saw some code whose purpose is still unclear to me. In the demos, an NSTimer is created, and then it is passed as arguement to a couple of NSRunLoop methods, as below.

What do these last two lines do? I look at apple's documentation but I am still unsure.

Also, what is the fastest timer available on MacOS X. NSTimer seems to be slow every now and then, which causes a lag in animation. This is especially true if I have many windows or apps open in the background. Even if I am doing nothing or next to nothing other than running the timer, it still lags when run over 30 fps on my G4 450mhz. Its brutally slow on my brother's 233mhz g3. I don't think 30fps of 540X440 animation is much to ask, so whats the deal? Is cocoa just slow?

Those lines attach the timer to the event loop, so it will actually fire. One attaches it for the normal case of the event loop, the other attaches it for when a modal dialog is on-screen. There isn't a function that will attach it for all modes at once.

I have had no problems with NSTimer, although I have noticed that applications like Mail can cause large glitches. When I was first building Smiley Tag, I had a timer running at a smooth 800FPS (admittedly on a 2x867 ;p).

If you're using OpenGL, you should be able to get 30Hz on your box no problems. Try setting the timer to fire far more often than you want it to (eg every millisecond) and see if that helps matters.

Thank you for the advise of setting up NSTimer to fire at very small intervals. The same NSTimer which was inconsistent when running at 30 fps is able to run at a relatively teady 250 fps when I ask it to run at 1000 fps. This will lead me to change my animation aproach. Before I would assume that the time between each animation frame was exactly equal (even though NSTimer fluctuates) and a sprite with a constant velocity would be moved the same number of pixel every frame. The problem with this approach is that on slow machines, say machines that can only provide 25 fps when you want 30, the result is that the sprite moving across the screne will move at a slower velocity. Instead, now I will vary the number of pixels a sprite moves (probably a fractional number) every frame depending on how much time has elapsed since the last frame was drawn while asking for 1000 fps but actually getting something small depending on the machine. This approach will not only give me a faster total fps but it also solves the problem of animation running in slow motion on slow machines.
Oh ya. OSC, you are right about Mail. It slows down other apps even more than explorer!!
A.W.