[GEM-dev] sharing texture between process

[Antoine Villeret]

2014-10-27 18:09 GMT+01:00 IOhannes m zmölnig <zmoelnig at 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 at lists.iem.at
> http://lists.puredata.info/listinfo/gem-dev
>