[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 #9 from Julien Isorce <julien.isorce at gmail.com> 2013-09-04 09:35:15 UTC ---
(In reply to comment #8)
> You mean one context for gleffects, one for glfiltercube!glimagesink and one
> for glimagesink rendering?

Correct :)

Yeah then initial reason of having a dedicated GL thread was to avoid
effectively switching  GL context from threads for each frame. And because of
we needed a thread for window event handling, why not using this thread as the
GL thread. So that's the story.

Now if we can know which streaming thread a glelement belongs to then we could
use glcontext sharing.

For example in pipeline videotestsrc ! gleffects ! queue ! glfiltercube !
glimagesink, 
gleffects would create a GstGLContext without a dedicated GL thread. When
initializing gleffects then just call "gl_context_make_current" when we need to
use gl functions. I think the cost of the context switch would not be a pb
during init and change state.
Once in STATE_PLAYING, gleffects::(*transform) will no cause any switch at each
frame.

Not sure if I'm clear :)

> > 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.
> 
> Unfortunately not currently, the pad task could also be created after the query
> in theory. The element owning the pad would know though.

Maybe the pad should be required to set "able_to_start_task" when creating the
pad. Then the marker would be set before the query ?

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