Personally, I'd recommend that you start with an NSTimer instead then, and switch to display link once you get that working. Display link GL examples are far and few between since the most popular way to do it for years has been with the NSTimer -- it's the beaten path. Display link is theoretically better (in practice it has not been for me, so I don't use it), but most importantly, you're likely to get higher fidelity help using an NSTimer path.

I did some more testing and it's not tearing it's something about the textures, some look torn and some cause extra large white sections to appear intermittently.

I swear I've seen something like that myself but I'm drawing a blank at the moment. This really could be the result of any number of things. Have you looked at the FAQ, specifically the section on how to debug?

Define "tearing". Is your scene split into two halves, top and bottom, where the line splitting the two moves up and down randomly?

Using DisplayLink doesn't magically enable VBL sync on your context. You still need it.

arekkusu Wrote:Using DisplayLink doesn't magically enable VBL sync on your context. You still need it.

My bad, I didn't read the docs correctly then. I read this here:

Quote:How often a frame is requested is based on the refresh rate of the display device currently associated with the display link.

Although, the sample code hints that you still need to turn on VBL synch, I don't recall reading that specifically mentioned in the docs.

The understanding I had was that the display link was driven by a high priority timer in a separate thread so that frames were timed to be requested (or drawn by OpenGL in this case) at exactly the same rate as they are needed by the display. I guess that doesn't mean any threads are "blocked" until drawing can take place? Would that perhaps be the point of VBL synch?

Yeah, okay, "timer", I get it now. It's high priority, but it's still a timer. NOT directly fired by the actual video hardware, just *timed* to synch *closely* with the hardware. Display "link" is a misnomer then IMHO.

Right-- you'll be notified to draw immediately after a display refresh, giving you the maximum amount of time during the next frame to do your work.

But, there's nothing stopping you from flushing early. Or drawing a billion triangles and flushing late. In either case, you still need to enable VBL sync to make your flush sync.

"Link" is still an accurate term, because it's fulfilling the vital need for a registering a software callback tied to a hardware IRQ.