We currently create the GstGLContext wrapping the sharing context and it's activated in the main thread. That means, among other things, that gst sends all gl operations on the context to the main thread. Another side effect is that the sharing context is made current in the main thread and remains forever.
Isn't gstreamer creating a new glcontext in its own thread (one of the many that it uses) and sending its gl operations there? I would expect so.
Pull request: https://github.com/WebKit/WebKit/pull/14583
(In reply to Miguel Gomez from comment #1) > Isn't gstreamer creating a new glcontext in its own thread (one of the many > that it uses) and sending its gl operations there? I would expect so. I don't think so, it does that when not creating a wrapping context.
(In reply to Carlos Garcia Campos from comment #3) > (In reply to Miguel Gomez from comment #1) > > Isn't gstreamer creating a new glcontext in its own thread (one of the many > > that it uses) and sending its gl operations there? I would expect so. > > I don't think so, it does that when not creating a wrapping context. hmm, it's not created for the wrapped context, but another one is created apparently, so I was indeed wrong. I'll continue checking, the patch would still be needed, though to avoid using the sharing context.
Ok, I see how it works now, our wrapped context is indeed only used as the sharing context of a gl context created by gst and used in a dedicated thread. I'm sorry for the noise, but this patch doesn't make sense as is. I'll close the PR for now.
It's only used as a sharing context, so it doesn't need to be activated and filled. This ways we avoid making the sharing context the current one in the main thread forever.
Pull request: https://github.com/WebKit/WebKit/pull/14586
Committed 264826@main (d4b48c265736): <https://commits.webkit.org/264826@main> Reviewed commits have been landed. Closing PR #14586 and removing active labels.
<rdar://problem/110158904>