[Bug 704809] Use one GstGLContext per streaming thread

[GStreamer (bugzilla.gnome.org)]

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

Matthew Waters <ystreet00> changed:

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

--- Comment #23 from Matthew Waters <ystreet00 at gmail.com> 2014-07-31 13:18:45 UTC ---
Review of attachment 278933:
 --> (https://bugzilla.gnome.org/review?bug=704809&attachment=278933)

This seems to combine three independent changes that should be split into
separate patches
1. offscreen signalling
2. changes to the offscreen EGL code
3. separate GstGLContext per streaming thread

There should be no MakeCurrent dances with GST_EVENT_EOS required to get this
to work properly, each thread has their own context (with optional gl thread)
and each element owns a ref on a context that is current in its thread.  When
the element is done with the context in the streaming thread, it unrefs the
context.

The other concern that I currently have with this is the integration with other
non libgstgl elements and even signalling between libgstgl aware elements. 
e.g. the thread parameter passed through the allocation query currently
describes the current streaming thread rather than the actual gl thread used.  

The other approach is to make the streaming thread == gl thread.  This has the
advantage of performance by removing the current function marshalling for all
GL functions.  The downside is that if you have a pipeline like so:
glfilter ! non libgstgl aware gl element ! glfilter 
all attempting to share the same streaming thread, then you need to figure out
some way to share gl state or force a new streaming thread at each library
boundary in the pipeline.  Or we just ignore this compatability problem.

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