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:

immediate mode:

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)

multiple windows:

if we have multiple openGL-contexts, we have to call the openGL-functions once for every context.

this means, that the RenderTrigger-message is sent once for each GemOutput.

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)

furthermore, it would be possible to change the gemlist for different GemOutputs connected to one gemcontrol. (this could also be thought of as a feature.)

i think that the RenderTrigger-message should only be emitted once per render-cycle (bound to a gemcontrol)

ideas:

• 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

  pros:

  + very simple to implement; does exactly what it is supposed to

  cons:

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

  pros:

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

  cons:

  • rather complicated...
  • we would have to build the DAG quite often which might be CPU-intensive
  • how to compare 2 DAGs ? (checksums?)
  • the postrender-bang of [t b a b] is not really what it seems to be
  • is this the return of [render_trigger] ?