I’m working with the API for an application called STK (Systems Tool Kit, similar to Google Earth). The API allows me to control when renders take place, but I don’t have immediate access to anything else, graphics wise. What I need to do is grab the renders from STK, bring them over as textures in my own OpenGL Context, and then modify them and display them in a new window.
Immediately after telling STK to render, I can grab the contents of the back buffer using either glCopyTexImage2D or glReadPixels. Of course, using glReadPixels copies the back buffer as a bitmap in main memory, so it’s very slow. I would like to use glCopyTexImage2D in order to avoid main memory, but I guess I can’t access the texture it creates from my separate OpenGL Context. I know that it is properly copying the back buffer to this texture, as I can save it to disk as a bitmap within the STK context, but it doesn’t show anything when I try to display the texture in my separate context.
When you say different applications I’m assuming these are indeed different processes with separate address spaces (not just different threads within one process). Under GLX there is GLX_EXT_import_context which, if I’m reading it correctly, makes it possible to share one OpenGL context between two processes.
Additionally OpenGL contexts normally maintain separate resources (textures, buffers, display lists) unless you request them to share these when creating the context, see glXCreateNewContex or the WGL extension WGL_ARB_create_context.
Please note that I’ve not done anything like what you are trying to do, so these are merely pointers at things that may be useful.
Thanks, I definitely appreciate getting pointers to things that may be useful. I’ll look into that stuff.
I misspoke when I said ‘different applications.’ It’s actually one process with multiple OpenGL contexts. Basically, I have a Windows Form application that loads a separate OpenGL (OpenTK) window/context. The STK API has these Globe Controls that you can drop onto a Windows Form. The Globe Controls are basically game windows…you can view the Earth, move the camera around, etc. So they’re a completely separate OpenGL context, but none of the actual OpenGL stuff is exposed to me. The Globe Controls have their own methods for setting the camera pose and such.
I have a button on the windows form that loads a separate OpenGL window when clicked. The Globe Controls have a method I can call to instruct them to render themselves, after which I can copy the render from the back buffer to a texture. But I then have to copy this texture to main memory in order to access it within my own OpenGL context, since my OpenGL context doesn’t have ownership of this texture.
Take a look at this for windows:
SDL2 also has support for shared OpenGL context. So you can use it or at last look at the source how it is implemented on the different target platforms.