[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

--- Comment #2 from Sebastian Dröge (slomo) <slomo at circular-chaos.org> 2013-08-27 08:30:35 UTC ---
(In reply to comment #1)
> In the actual gst-plugins-gl 1.0 can we can create a gl context without a
> window ? If no then we have to add this feature if it's really possible. I mean
> can we share 2 gl contexts if one is setup with off-screen and the other with
> on-screen surface ?

In theory yes, it probably depends a bit on the backend. For WGL you can only
create invisible window surfaces, not real offscreen surfaces AFAIK.

Sharing between contexts should work in theory, Matthew checked that. It has to
be implemented though ;) And there should also be a fallback path that
downloads&uploads when moving between contexts if nothing more optimal is
possible.

> Anyway I'm wondering if we could use the streaming thread as the gl thread
> (except for the final drawing thing done by glimagesink). See solution 2.
> 
> For example in videotestsrc ! gleffect ! queue ! glfiltercube ! glimagesink
> there are 2 streaming threads, the first one (called A) involved in
> videotestsrc ! gleffect, and the second (called B) involved in queue !
> glfiltercube ! glimagesink
> 
> 
> 1) The first improvement would be to create one GstGLContext A for the
> streaming thread A, shared with the GstGLContext B for the streaming thread B.
> In this case it would have 2 streamings thread and 2 GL threads (1 GL thread
> per GstGLContext)
> 
> 2) The second improvement would be to use the streaming thread as a GL thread.
> In our example, streaming thread A would be the GL thread associated with
> GstGLContext A. Streaming thread B would be the GL thread associated with
> GstGLContext B. Then we would still need another GL Thread with GstGLContext
> created by glimagesink for drawing purpose.
> 
> With this second solution we would need the ability to be able to create a
> GstGLContext without creating a new thread and without running a loop into it.
> Just call make current and other gl calls directly in that thread :)

Sounds like a plan, but 1) as a first step would already make me happy enough
:)

> ** With solution 1) and 2) we would need to know in which streaming thread we
> are in GST_QUERY_CONTEXT. If we are in the same then we use it directly but if
> we are in an other streaming thread then we share. How to do that ? Improve
> GstContext ? Is there a GST_QUERY_STREAMING_STATUS ? I only saw examples with
> messages.

There's nothing yet for that, we need to add API for that. I think it should be
part of the ALLOCATION query (as said in the other bug, GstContext should here
probably only be used to share GstGLDisplay, not GstGLContext and thus not the
threads).

> With solution 2) we would also need to be able to ask for calling a callback
> into the streaming thread. I mean if we need to ask for calling a GL function
> in the streaming thread from set_caps (or get_caps or any other function of an
> gl element) . Not sure if it is possible as the GstTask does not run
> g_main_loop so we cannot use g_timeout_callback for example.

Problem with that is that it's not even guaranteed that the streaming thread is
ever active again. I'm not sure how feasible this is going to be.

> An other question, in GstBaseTransform, which virtual methods are "100%
> garanti" to be called in the streaming thread the element belong 
> ?http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/GstBaseTransform.html
> Only (*transform) ?

And set_caps at least, and the event ones for serialized events.

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