[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 #8 from Sebastian Dröge (slomo) <slomo at circular-chaos.org> 2013-09-04 09:13:24 UTC ---
(In reply to comment #7)

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

You mean one context for gleffects, one for glfiltercube!glimagesink and one
for glimagesink rendering? Or I misunderstand completely :)

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

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