2014-10-27 18:09 GMT+01:00 IOhannes m zmölnig <[email protected]>: > 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 > [email protected] > http://lists.puredata.info/listinfo/gem-dev > _______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
