CVDisplayLink - ObjectiveC & C++ - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Graphics & Audio Programming (/forum-9.html)
+--- Thread: CVDisplayLink - ObjectiveC & C++ (/thread-10123.html)
Pages: 1 2
RE: CVDisplayLink - ObjectiveC & C++ - dauerbach - Oct 2, 2012 10:57 PM
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?
Thanks for the GL tips...
RE: CVDisplayLink - ObjectiveC & C++ - AnotherJake - Oct 2, 2012 11:20 PM
(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
RE: CVDisplayLink - ObjectiveC & C++ - OneSadCookie - Oct 3, 2012 10:20 AM
Just use pthread/NSThread.
Do use NSOpenGLPFADoubleBuffer.
Don't call glFlush().
Probably don't try to share resources between your GL contexts.
RE: CVDisplayLink - ObjectiveC & C++ - dauerbach - Oct 3, 2012 11:23 AM
I apologize for dragging this thread off-topic...
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.
RE: CVDisplayLink - ObjectiveC & C++ - OneSadCookie - Oct 4, 2012 01:35 PM
Yes, you will have to manage your data and synchronization carefully!