2014-10-27 18:09 GMT+01:00 IOhannes m zmölnig zmoelnig@iem.at:
On 10/27/2014 10:41 AM, Antoine Villeret wrote:
hello,
since texture sharing seems to work between context inside one Gem's instance, I'm now wondering how we can introduce texture sharing between process. According to [1], texture (and more generally display list) can be shared between process if direct rendering is disabled and process are using the same X server.
in order to do context sharing, you need to have a reference to an "original" context (with which you want to share). i do not see how you can achieve this between different "processes".
isn't it possible to handle this original context in the first Gem instance and put it in a shared memory ? then in the second Gem, couldn't we use that first context in glXCreateContext() ?
If I understand correctly, the only thing to do is to share the display list structure over process. Could we use shared memory to do that ?
yes, probably (once we have found out how to create such a shared context).
I look into the [gemglxwindow] and [gemglutwindow] code and it looks a bit obscure to me, it uses advanced C++ idioms (PIMPL for the former and CALLBACK4WIN for the latter)
not very advanced. PIMPL just stands for "Private IMPLementation" and is an idiom to hide implementation details from the public header files (by using a pointer to a private class): this basically means that you can change the private data (e.g. add new members), without having to touch the header files (great somebody else includes the header and you don't want to break binary compatibilty). it also allows to use class-local functions (in the PIMPL) without having to add new methods to the class (in the main class). it's really all about keeping the public interface of a class minimal.
CALLBACK4WIN is simply a macro that tries to get the handle to the "correct" gemglxwindow instance for a given glut-callback (glut will not provide any "user-data" in the context; however it's possible to find out which window emitted the callback; CALLBACK4WIN then uses a map to query the gemglxwindow instance for the given window id)...
thanks for the explanation, you know, I learned C++ with Gem and those "not-so-advanced" uses are quite rare in Gem's code :-)
what's more important: afaik, glut does not allow context sharing at all (there's nothing in the API that would handle such a case).
with examples/14.multiple_windows/03.texture_sharing.pd and [gemglutwindow] I got a texture on both windows.
afaik, only glx and glfw3 have an API that allows context-sharing.
but [gemglfw3window] doesn't allow texture sharing yet.
+ a
gfamdsr IOhannes
GEM-dev mailing list GEM-dev@lists.iem.at http://lists.puredata.info/listinfo/gem-dev