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

Julien said:
> > 
> > > 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.
> > 

Sebastian said:
> > 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.
> 

Julien said:
> 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.


I think I have an other idea; instead of having a dedicated GL thread for each
streaming thread,  just call "make_current" when we need to use a GL function.
When changing element states, the cost of switching context does not matter. In 
(*transform) function, where we need to be fast, then calling "make_current"
would have no effect because it's already current (except for the first time,
but I think this case would happen when going to STATE_PAUSED)

So to resume for pipeline videotestsrc ! gleffects ! queue ! glfiltercube !
glimagesink:  2 GstGLContexts that are switchable (one "associated" with each
streaming thread, but can be set current in other thread if needed (*get_caps),
anything else)function), + 1 GstGLContext that creates a GL thread associated
with glimageinsk for drawing and windowing purpose.
The 3 contexts would be shared together.

Also when initializing GstGLContexts, I mean when using GST_QUERY_CONTEXT /
GST_QUERY_ALLOCATION, would it be possible to know we are using another
streaming thread by looking at if the src pad is creating a GstTask ?

For example when a query goes from queue_pad_src to queue_pad_sink it should
have a way to know that queue_pad_src uses a GstTask. Maybe when calling
gst_pad_start_task (a_pad, ) then a_pad should be marked as handling a new
streaming 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.