display link to drive opengl loop?

Moderator
Posts: 3,577
Joined: 2003.06
Post: #16
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.
Quote this message in a reply
Apprentice
Posts: 15
Joined: 2009.01
Post: #17
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.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #18
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?
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #19
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.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #20
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?
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #21
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.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #22
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.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Error trying to link an OpenGL app memon 4 3,714 Mar 19, 2007 12:33 PM
Last Post: memon
  OpenGL Program / Loop Help Jones 5 2,994 Jan 4, 2006 08:36 PM
Last Post: Jones
  Texturing with OpenGL & Cocoa (link) Taxxodium 0 2,461 Dec 2, 2004 06:31 AM
Last Post: Taxxodium
  OpenGL profiler & display lists MattDiamond 9 4,302 Sep 1, 2003 08:07 PM
Last Post: MattDiamond