[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 #3 from Julien Isorce <julien.isorce at gmail.com> 2013-08-27 09:56:48 UTC ---
(In reply to comment #2)
> (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.

Ok this is what I remind now :)

> 
> Sharing between contexts should work in theory, 

Could you clarify ? I mean what should work compared to gst-gl-0.10 ?

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

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

I'm not convinced :)
I think GstGLDisplay should be removed, and merged into GstGLContext. I mean in
the gstgl history gstgldisplay should had been called gstglcontext from the
beginning.

Currently in HEAD what is the goal of GstGLDisplay ? Almost just be able to
call gst_gl_display_thread_add. Why not just move it to GstGLContext ?

Also I do not see a use case where we would need to use a GstGLDisplay without
a GstGLContext.

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

Ok so we could combine 1) and 2),
I mean we could keep 1) (when it's done) and then be able to use the streaming
thread as a GL thread only for (*transform). During init and conf it does not
matter to use a dedicated GL thread, but in (*transform) this is where we need
to be fast :)

It implies de have one more GL context and I think on some platform we have a
limited number of gl context ?

Well, for the "every day" pipeline videotestsrc ! gleffects ! glimagesink
it would implies to create 2 GstGLContext: 1 which use the streaming thread, 1
which create a GL thread

For videotestsrc ! gleffects ! queue ! glfiltercube ! glimagesink  : 4
GstGLContext, 2 thats use a streaming thread, 2 that create a gl thread.

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