[GEM-dev] sharing texture between process

[IOhannes m zmölnig]

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".


> 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)...


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).

afaik, only glx and glfw3 have an API that allows context-sharing.

gfamdsr
IOhannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20141027/c0bf5eed/attachment.sig>