[gstreamer-bugs] [Bug 578811] crash with cocoa backend

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=578811

  GStreamer | gst-plugins-gl | Ver: git




------- Comment #5 from Julien Isorce  2009-07-27 08:48 UTC -------
G.P. : 

"
Neither objc_mutex_t nor objc/thr.h exists on Mac OS X.

There are two Objective-C runtime implementations: the one originally written
by NeXT, and the one originally written for GNU. They both implement the same
language (more or less), but their internal structure, file formats, and
introspection API are incompatible. Mac OS X uses the NeXT runtime, and gcc
includes the GNU runtime to be used on platforms other than Mac OS X.

GSRegisterCurrentThread() tells the GNU runtime about a non-NSThread. There's
no need to do that on Mac OS X unless you're using the garbage collector.

As far as I know there is no way to reassign the main thread. The main thread
must always be the one started by the kernel at process launch.
"


My approach was to reassign the main thread and so make the gl thread the main
thread. Then I could run the nsapp loop in the gk thread. But it's only
possible with GNUstep. Moreover it causes problems when using several
glimagesink, because it was attempting to have several main threads and this is
not possible.

So I changed my approach a little bit.
We have two cases : non-embedded (gst-launch), and embedded (cocoa application)

The nsapp is initialized at gstglwindow class initialization to make sure the
nsapp is initialized only one time (for multiple sink).
In non-embedded mode the nsapp is initialized in the main thread through the
g_main_loop (which is runnning in the main thread when using gst-launch).
In embedded mode the nsapp is initialized by the user in his client code (see
gst-plugins-gl/tests/exampples/cocoa/videoxoverlay/main.m)


In the gl thread I am now running a NSRunLoop associated with the NSThread
(which is associated to the gl thread)
This loop performs all OpenGL calls and hanldes the events of the non-embedded
window.
In embedded mode, this loop only handles OpenGL calls.(the gl context is made
current only one time).
Also in embedded mode, the user can run the nsapp as normal. (see
gst-plugins-gl/tests/exampples/cocoa/videoxoverlay/main.m)

commit 6f80b865d5fb7e7cf70541324abb985ce48ba0ef    
Author: Julien Isorce <julien.isorce at gmail.com>    
Date:   Mon Jul 27 09:58:20 2009 +0200             

    Cocoa backend: make sure that nsapp is initialized

    gst-launch-0.10 videotestsrc ! tee name=t ! queue ! glimagesink t. ! queue
! glimagesink
    now works properly on MacOSX                                                

commit db69e930c5ef485f6ba16dd79af8e2da71a617ce
Author: Julien Isorce <julien.isorce at gmail.com>
Date:   Fri Jul 24 10:12:07 2009 +0200         

    Cocoa backend: fix crash when closing

    - All gstglwindow members are now modified only in the gl thread
    to avoid thread concurrency
    - OpenGL context is now properly clean
    - fix a couple of things in implementation of xoverlay interface

commit f13d38b8e76974792905b2beb9aa01cf0a6af261
Author: Julien Isorce <julien.isorce at gmail.com>
Date:   Fri Jul 17 16:47:41 2009 +0200

    make cocoa backend work on MacOSX

    It works with both gst-launch and a cocoa app (non-embedded and embedded)
    But there is still some problems:
      - sometimes crash when closing
      - flickering when resizing
      - embedded mode not perfect

    I will first make the CMake build work with cocoa backend
    in order to generate a XCode project.
    Then it should be easier to fix those issues.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=578811.