each render cycle, the render()-method of all objects within the gemlist has to be called. therefore, the gemhead emits a render-trigger (a specially crafted message) which is sent to the connected objects, which in turn send the same message out again.
this works pretty well and it allows to dynamically change the gemlist with pd's message control objects, like [spigot].
unfortunately there are problems:
due to the dynamic nature of the gemlist, it cannot be compiled into a display-list, thus enforcing rendering in ''immediate mode'', which is way slower (esp. on os-X)
if we have multiple openGL-contexts, we have to call the openGL-functions once for every context.
i do not like this at all, as it means, that the behaviour of the patch could change by just adding another GemOutput (e.g.: i sometimes use the RenderTrigger to derive a ![bang( which controls some animation or the like)
- the simplest solution is to use shared display-lists:
each gemlist is compiled into a display-list once a render-cycle.
the consecutive calls of the gemlist are as simple as calling the display-list
+ very simple to implement; does exactly what it is supposed to
- unfortunately this does not work everywhere (display-list sharing is not possible across multiple openGL-servers)
- sending out a "RenderTrigger"-message that does not actually call the render()-function but is used to build a graph of the objects involved.
this graph of render()-functions is then executed without pd's messaging system. this is very much like the DAG (Directed Acyclic Graph) of the old Gem, but now the DAG would be compiled every render-cycle.
+ this would also enable the use of display-lists (even on a per server basis!), as we could compare the current DAG with the last one, and decide whether we have to recompile the display-list.
+ probably is also a solution for GemThreads (running Gem in a separate thread)