I have been using SDL for a long time. Now I am in the midst of building a windowed cocoa-based OpenGL app.

Do I have to use a timer to call setNeedsDisplay in order to invalidate the view?

In my SDL app, I would simply draw as fast as possible- e.g. calc elapsed time and then render within the main loop.

I was wondering if it was possible too have the view invalidate itself as soon as it draws? I tried calling setNeedsDisplay at the end of displayRect, but that does not work. I want the view to redraw itself as fast as possible, perhaps every refresh?

If not, is the resolution of NSTimer high enough to guarantee a redraw every screen refresh?

Thanks for any advice....

Yes. <extra characters to pacify forum>

Just set the timer to repeat every 0.001 seconds, which is 1 kHz, and turn on vbl synch and you'll be rockin'.

How do you turn on vbl sync for Cocoa views? ... I thought they were automatically synced, by virtue of being standard Cocoa views.

They still need vbl synch (NSOpenGLViews need vbl synch, not NSViews):

long vblSynch = 1;
[[self openGLContext] setValues:&vblSynch forParameter:NSOpenGLCPSwapInterval];

ARG. My mistake -- I didn't see in the original post that he's using Cocoa-based OpenGL. I thought he was using vanilla Cocoa/CG 2D drawing & animation.

AnotherJake Wrote:long vblSynch = 1;
[[self openGLContext] setValues:&vblSynch forParameter:NSOpenGLCPSwapInterval];

"long" should be "GLint"

Yep, I'll be darned. I don't know how I got away with that for all this time. I fiddled with it just now and the compiler caught it, but didn't previously... hmph... I wonder what possessed me to use a long in the first place?

It changed in 10.5.

On 10.4 and below, -[setValues:forParameter:] takes a "long*", and GLint is typedef'd from "long", so using GLint works, even if that's not precisely what the headers suggest you should do.

On 10.5, for 64-bit compatibility, Apple revisited all the integer types in all their APIs, making conscious decisions as to whether they should be 32- or 64-bit. GLint *has* to be 32-bit since it's fed to the video hardware, so it had to change from long to int. I'm a little surprised that -[setValues:forParameter:] was also identified to change, but it clearly was, and someone clearly decided that since GLint fit the bill of "a type that's long on 10.4 and int on 10.5" that's what the values parameter should become.

That little footnote had completely slipped by my attention! Well, at least I'm not *quite* as crazy as I thought. But now that brings up the question of what other data types changed. Guess I'll just have to keep my eyes peeled. I had changed the SDK for that project to 10.5 and cleaned it and it never caught that type change until I fiddled with it.

[Off-Topic] Grr... I wish I could more easily keep up with all the changes Apple does. I'm still stumbling around with the new Xcode and IB. I'm not really happy with the new tools. It's probably just my crappy attitude toward things at the moment, but it seems like the quality of Apple's stuff is beginning to collapse under it's own weight and disorganized complexity.

Lots of other types changed, in particular, almost every int or long in Cocoa became NS(U)Integer... but not quite all

I find Xcode 3 a slight improvement over Xcode 2, and IB3 a major improvement over IB2...