How to share GL context with an external library?

#1

hi friends,
I have an external library (libvlc v4 video player) that decodes video frames on a GL texture, that then needs to be drawn on screen. In order to do this the GL context needs to be shared with this library, but I do not know how this could be done.

The textures are created in a callback, so that part is controllable if needed. Looking at the docs and source code I see that an GLFW window can share context with another window, but how to do the same with a generic entity? The sample code (that works) using SDL just puts this at the beginning of setup.

SDL_GL_SetAttribute(SDL_GL_SHARE_WITH_CURRENT_CONTEXT, 1);

A solution that does not need patching of OF code would of course be preferred, but this is not a mandatory requirement.

A big thank you to anybody knowledgeable (and kind :blush:) enough to help
cheers
Davide

#2

As far as I know, you can not share the GL context because openGL it is single threaded, what you can do, as far as I know, is to share a texture. I know it is possible to share the texture between two windows, but I do not know how does it work when these two windows come from 2 different application.

#3

This is isn’t really related to threads and indeed you can share resources between two shared contexts in different threads.

The problem is that glfw, the library we use to create the GL window and context, only allows to share the context with another glfw window and I think there’s no way to share it with other libraries. I would ask in the glfw forum or even open an issue in the glfw github since this is something that would be useful for other cases.

#4

Just to understand this better, when you say “resources”, what are you referring to? and when you say “two shared context”, you mean two different applications, each one with its own context?

#5

No, in the same application. You can have multiple threads each using a different opengl context. if those contexts are shared you can then use some resources (like textures, vertex buffers and in general anything that is data not gl state) in common from both threads

#6

Well the textures to be shared with the library are created in a callback that is under control, being part of the code we re writing in our application. A possible solution could be creating a second (invisible) GLFW window in main.cpp, share its context with main window and somehow use it to create the textures to be share.

But what will happen regarding threads? This way the invisible window would be created in the main thread, and I do not know if and how a different thread will be able to write in its textures.

I hope you understand what I am trying to say, my knowledge of openGL (and English) is shallow at best :sweat_smile:

#7

From the SDL call you post it looks like that library is creating it’s own context and using it to fill the textures. You need to share your context with the one that the library creates to be able to share the textures but glfw doesn’t allow to do that.

#8

I tried to replicate the SDL code with some GLFW that looked more or less equivalent, may be it could work… the idea is to create a second (invisible) window with its associated context and share it with the main one, that’s more or less what SDL does for what I can understand.

The context is not created by the library but it is somehow passed to it, as far as I can see, this could be helpful.

For testing I wrote a simple app that can be used to experiment with the library, at the moment it builds but of course do not display anything. By the way how can you draw a texture of which you have the ID to the screen (or an fbo for the matter)? I feel this should be a trivial thing but yet can’t figure it out :confused:

It would be great if someone would take the time to play a little with these and see if the general idea may work. The code can be found here