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