[Bug 731525] multiple glimagesink elements aborts due to no XInitThreads.

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #2 from Matthew Waters <ystreet00 at gmail.com> 2014-06-12 08:48:52 UTC ---
(In reply to comment #1)
> Do you mean that "gst_gl_ensure_display" make them use the same GstGLDisplay
> instance  ?

In order to share glx contexts with intel linux drivers, the X Display
connection has to the same, it does not matter how they are the same, just that
they are.  It is an implementation detail that that X Display for glx contexts
comes from the GstGLDisplay.

> Maybe we could ensure thread safety ourself: renaming
> "gst_gl_display_get_handle":
> to "gst_gl_display_acquire_handle"  and adding "gst_gl_display_release_handle".
> 
> The caller would be responsible to release it when done.

I thought about this and determined it infeasible.  The problem is that it
would require app/toolkit buy-in due to the thread separation between the
app/toolkit's main thread and GStreamer's streaming threads.

Take clutter for example, in order for us to share contexts with clutter, the
display connection has to be the same (for intel linux drivers).  So a good app
provides the clutter X display to libgstgl using GstContext.  Now imagine that
clutter, without knowing about libgstgl or any of its GstGLDisplay
synchronization, performs it's own glX calls at a similar time as libgstgl.  If
they overlap (without XInitThreads) BOOM, xcb will abort the app.  Not good.

> The bad thing is that it adds a locking at client level, so 2 glXSwapBuffers
> (x11_display_handle, window_handle) would never happen at the same time within
> the same pipeline.

No two glX calls can be running at the same time.

> But I think it would be the same result with XInitThreads, plus it adds the
> constrain to all pipelines. Anyway I guess at some point there is a locking
> mechanism at server level if not using the same connection.
> Good thing is that we avoid 1 and 2.

The other bad thing is that all of the other display systems are already
thread-safe enough to ignore this issue so we would be doing this only for X11. 

> Also when using only one glimagesink, the same problem will happen when having
> one one GLThread per streaming thread and having gleffects ! queue !
> glimagesink.

Yes, very possible.  However mitigated by the timing issues of the ALLOCATION
query.

> In the end I would prefer to go for a solution where we have the hand on the
> locking.

See above

-- 
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.