[Bug 741054] gl/cocoa: Simplify NSApplication initialisation for console apps

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=741054
  GStreamer | gst-plugins-bad | unspecified

Sebastian Dröge (slomo) <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #292038|none                        |reviewed
             status|                            |

--- Comment #2 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-12-03 10:19:58 UTC ---
Review of attachment 292038:
 --> (https://bugzilla.gnome.org/review?bug=741054&attachment=292038)

While this fixes one deadlock, it causes other problems :(
Using the GDK approach also seems not wise inside libgstgl as we would severely
modify the default main context behaviour... after a main loop is potentially
running on it already.


Not sure what to do about this. Note that using the approach from osxvideosink
can't be used here although it is "perfect" there... the osxvideosink approach
will cause deadlocks and assertions if any of the GL related code uses the GCD.
Our own usage of it can be removed relatively easily and replaced by calling
selectors instead like in osxvideosink, but there's nothing that prevents other
code to use it. The problem with the GCD is that we can't seem to fake that the
"main thread" is a different one for it, while for NSApplication that part
works.


Maybe GMainContext/GMainLoop should directly do the stuff GDK does when running
on OSX/iOS. When the default main context is acquired from the NSApplication
main thread. That would solve all our problems at once.

::: gst-libs/gst/gl/cocoa/gstglcontext_cocoa.m
@@ +159,1 @@
     } else if (g_main_context_acquire (context)) {

Not your fault, but this is racy :)

Consider the following standard situation:
1) gst_element_set_state(playbin, GST_STATE_PLAYING)
2) g_main_loop_run(loop)

Now between 1) and 2) we could get to the above code if we're fast enough and
successfully acquire the default main context... while actually everything
would be ok.

@@ +199,3 @@
   __block NSOpenGLContext *glContext = nil;

+  if (!g_atomic_int_get (&nsapp_init_done)) {

This will break if:
- class_init() is run from some arbitrary thread (e.g. streaming thread in
playbin), thus not the NS main thread
- No GLib main loop is running on the default main context
- We have a real Cocoa application

That is, the default case if you develop a real Cocoa application and don't
accidentially call class_init() from the main thread. Previously this probably
would've resulted in a GST_WARNING() too

@@ +202,3 @@
+    /* Probably not scheduled in the idle callback yet */
+    GST_WARNING ("NSApp not yet initialised, trying to wait");
+    g_usleep (1 * G_USEC_PER_SEC);

1 second seems to be a bit big :)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.