Thanks for the response. Since writing this, I've tried to better understand
this C code, and my understanding of the problems here might have not been
correct. They still probably aren't correct, but I'll try to better articulate
the challenge.
I tried all of the techniques you suggested, none of them seemed to work. With
my limited understanding of this C GStreamer code, I think the problem area is
in this function of the codebase:
https://github.com/GStreamer/gst-plugins-bad/blob/8d99867c13944be9ba75a892682204955f16f586/gst-libs/gst/gl/cocoa/gstglwindow_cocoa.m#L421-L448
When initialized this code seems to create a new GCD dispatch queue:
(__bridge_retained gpointer)
(dispatch_queue_create ("org.freedesktop.gstreamer.glwindow", NULL))
It then periodically dispatches work to this queue.
My understanding of how GCD dispatch queues work is practically nonexistent,
but I'm under the impression that work is executed off these queues through
some Cocoa mechanism off the main run loop, as before. Do you know how I might
ensure that this work is executing or am I way off the mark?
Thanks.
On Mon, Jan 22, 2018, at 10:31 PM, Matthew Flatt wrote:
> Sorry for the slow response!
>
> At Thu, 11 Jan 2018 12:56:02 -0500, Mark Wunsch wrote:
> > Yes — that's perfect, thank you! And it also gives me a better sense of how
> > racket/gui is implemented for macOS. This snippet of code is now included
> > in
> > my library, and I wonder if there's benefit to having this be available in
> > racket/gui for cross-platform usage?
>
> The snippet seems fairly specialized to me, and I'm not sure there's a
> useful cross-platform interpretation.
>
> > Now that I understand this a bit, I tried solving the second use-case I
> > wrote
> > about, using the glimagesink. My understanding of this code is that it
> > creates
> > a subview with a CAOpenGLLayer, and then enqueues a `setNeedsDisplay`:
> > https://github.com/GStreamer/gst-plugins-bad/blob/8d99867c13944be9ba75a89268220
> > 4955f16f586/gst-libs/gst/gl/cocoa/gstglwindow_cocoa.m#L332-L354
> >
> > When I run equivalent code outside of racket (e.g. through the gst-launch
> > tool), I see that I continuously see calls to draw
> > (https://developer.apple.com/documentation/quartzcore/caopengllayer/1522316-dra
> > w). Those calls are not being made when run from Racket.
> >
> > I realize we're venturing outside of the Realm of Racket (intentional pun)
> > and closer to Cocoa, but I'd like to have a better sense of how to dequeue
> > these drawing actions. Based on your previous code, I thought that I could
> > yield to the main thread by calling `run` or `runUntilDate` on the main
> > NSRunLoop, but that didn't seem to accomplish this goal.
> >
> > Any ideas of how to "yield" to whatever queue or thread GStreamer has
> > running?
>
> I'm not sure I'm following, but I think a `setNeedsDisplay` on a view
> within a `racket/gui` frame will triggers a refresh callback in the
> normal `racket/gui` event queue.
>
> Does the `yield` function from `racket/gui` allow the callback to run
> in the way you expect? I'd try `yield` applied to a semaphore that's
> posted by a low-priority callback installed with `queue-callback`,
> since refresh events will happen with higher priority.
>
> There's also `flush-display`. For various reasons, `flush-display`
> rarely helps, but it may be worth a try.
>
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
