[GEM-dev] sharing texture between process

IOhannes m zmölnig zmoelnig at iem.at
Tue Oct 28 08:53:32 CET 2014


On 10/27/2014 07:18 PM, Antoine Villeret wrote:
> 
> thanks for the explanation, you know, I learned C++ with Gem and those
> "not-so-advanced" uses are quite rare in Gem's code :-)

you know, I also learned C++ with Gem, and only introduced those
"not-so-advanced" techniques recently when i learned about them :-)

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

yes, thats the idea.
Gem should not only support "multiple windows" but also "multiple
contexts" (that is: it ought to work even if two windows can NOT share
textures, display-lists,...); this is what GemContextData is for: the
problem is that two different contexts may choose to generate to
different IDs for something (like a shader module).
i'm currently thinking about having a map between t_atom (t_float
really) and context-specific data, so we an object like [glsl_vertex]
will only output a single ID and the consumer ([glsl_program]) can get
the various context-specific IDs from this single number.

> 
>>
>> afaik, only glx and glfw3 have an API that allows context-sharing.
> 
> but [gemglfw3window] doesn't allow texture sharing yet.
> 

yes. but we can add it (whereas we cannot add it with [gemglutwindow])



gdsr
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/20141028/2e8df009/attachment.sig>


More information about the GEM-dev mailing list