Can CVDisplayLink be used with Xojo

I’m trying to set up the code here for Setting up a Core Video display link, well I have but get a StackOverflowException when the callback is triggered.

Despite the StackOverflow I think it could be the callback signature that isn’t right. The method is never entered or code executed, instead the last ‘end’ line is marked as the exception and my Window turns Nil in the debugger. Also the stack only shows my single callback, no StackOverflow?!

This is the callback signature and types specified in the docs…

[code]CVReturn MyDisplayLinkCallback (
CVDisplayLinkRef displayLink,
const CVTimeStamp *inNow,
const CVTimeStamp *inOutputTime,
CVOptionFlags flagsIn,
CVOptionFlags *flagsOut,
void *displayLinkContext
);

typedef uint64_t CVOptionFlags;
typedef int32_t CVReturn;[/code]

and what I came up with in Xojo where I’ve tried many variations for flagsIn/Out, as Ptr, byref, etc…

Shared Function impl_DisplayLinkHandler( dLink As Ptr, inNow As Ptr, inOutputTime As Ptr, flagsIn As UInt64, flagsOut As Ptr, dLinkCtx As Ptr ) As Int32

All the setup code seems to work, no errors from the CV functions, Ptrs are valid, but this StackOverflow thing is throwing me. Any ideas?

Xojo & frameworks are not thread safe and async callbacks into it will have issues
I suspect this is one - Joe could confirm better than I can
That looks to be a requirement for this CVDisplayLink
https://developer.apple.com/library/mac/documentation/GraphicsImaging/Conceptual/CoreVideo/CVProg_Tasks/CVProg_Tasks.html#//apple_ref/doc/uid/TP40001536-CH203-DontLinkElementID_10

Norman’s correct. Xojo uses a cooperative threading model, which means that the runtime has to know about all threads that can run Xojo code and only one thread can be running Xojo code at a time. CVDisplayLink invokes the callback on the display link thread, which isn’t managed by Xojo.

I’m afraid there’s no way to do what you’re after without writing a plugin in C or C++. In that plugin, you could get the callbacks on the display link thread and shuttle them over to the main thread with something like dispatch_async. I’ve not used CVDisplayLink, so I’m not positive the overall impact that would have on performance or functionality.

I was afraid there might be no way, this is promising :slight_smile: I’ve made very small plugins before and like a challenge.

What I’m after is a way to sync OpenGL drawings with screen refreshes so I don’t have to draw at 90fps with a Timer to get smooth 60fps motion.

Thanks Joe for giving me a track, very helpful, and thanks Norman for another link I should have had :slight_smile:

As someone with a laptop, I’d like to say “thanks for trying to do things right”. Far too many games either peg the CPU at 100% or use timers which are better but still have problems with sync and wake ups.

Sadly I don’t think my idea of using dispatch_async would be well suited for your purposes: there’s no guarantee as to how soon the main queue will be serviced and your block executed. I almost think you’d need to have your game logic create data structures representing what needs to be drawn (e.g. a scene graph) and have the C++ code running in the plugin read from that and generate the required OpenGL calls…

On top of that, there’s the classic problem of pre-emptive threads: the game-created data structures can’t be modified while the pre-emptive thread is trying to read from it. One idea that comes to mind is to use a dispatch_semaphore, since they’re generally cheaper than pthread mutexes. As is typical with locks, you’d want to keep the time spent holding the semaphore as short as possible since it will either block the display link thread or the Xojo thread (well, all Xojo threads). Add on top of that the restriction that you can’t call into the Xojo runtime (including any plugins SDK functions) from a non-Xojo thread and the problem gets more fun.

I wish I had a better answer for you, but doing pre-emptive threading is hard and trying to mix that with Xojo code is even harder. I guess just be glad you’re not trying to use Core Audio where you’ve got more or less real-time threads where you can’t take locks of any kind.