CVDisplayLink - ObjectiveC & C++

Apprentice
Posts: 5
Joined: 2012.10
Post: #16
Thanks again...

Is it that the Timer is "blocked"? And won't fire more than 60fps? or that the OpenGL will only really draw at 60fps no matter the frequency at which the OpenGL code is executed?

You may be right about the GPU round trip, I will do some more testing to see if running that calc on the CPU changes the behavior any.

And if I get rid of the OpenCL/GPU number crunching, what would be the currently recommended approach for putting each window's NSTimers in there own thread?

1) Create an NSThread and add timer to thread's runLoop?
2) GCD (oy, more reading to do)
3) Create an NSOperation that creates and runs the tNSTimers?
4) ???

Thanks for the GL tips...
Quote this message in a reply
Moderator
Posts: 3,574
Joined: 2003.06
Post: #17
(Oct 2, 2012 10:57 PM)dauerbach Wrote:  Is it that the Timer is "blocked"? And won't fire more than 60fps? or that the OpenGL will only really draw at 60fps no matter the frequency at which the OpenGL code is executed?

OpenGL will draw when it's told, so 60 fps is not a limit. I don't know the specifics of the underlying mechanics, but the GL thread, i.e. the timer thread, is blocked (at the flush?) until the next VBL arrives when VBL synch is enabled. Setting a high timer rate with VBL synch just helps to ensure your GL frame is already drawn and ready to go by the time the next display refresh arrives and unblocks it.

As far as the threading thing, I would recommend to wait just a bit before you jump on that to see what others have to say here about the OpenCL texture generation. No need to make things more complicated than necessary if you can avoid it Wink
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #18
Just use pthread/NSThread.

Code:
[context makeCurrentContext]; while (1) { drawScene(); [context flushBuffer]; }

Do use NSOpenGLPFADoubleBuffer.
Don't call glFlush().
Probably don't try to share resources between your GL contexts.
Quote this message in a reply
Apprentice
Posts: 5
Joined: 2012.10
Post: #19
I apologize for dragging this thread off-topic...

@OneSadCookie:
I assume I need to be concerned with the fact that there are a few parameters to my scene creation calculation that are going to be changed from outside the thread as the thread runs. Yes? Essentially, based on UI input from the "control" window on the 5th display, the image to be shown on each display will change. I currently have this set up using KVO from the GLViews looking back up to this control window.

thx!
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #20
Yes, you will have to manage your data and synchronization carefully!
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  CVDisplayLink instead of NSTimer OptimisticMonkey 6 7,367 Nov 18, 2009 02:49 PM
Last Post: SethWillits
  Interesting Articel on CVDisplayLink OptimisticMonkey 1 4,069 Dec 28, 2008 11:15 PM
Last Post: AnotherJake