changed:
-
note: 
  "context" is not really an openGL-context. 
  it is a [gemcontrol] with the connected [GemOutput](s); we might call it GemContext

-  We need to be very clear about the separation between GL-contexts and Gem-contexts!

- perhaps offscreen rendering would be it's own form of [gemcontrol]?  or just a [gemframebuffer] or [gempbuffer] associated with it's own [gemcontrol]?


idea: 
  use symbolic names to name contexts; named [gemhead]s are associated with the according [gemcontrol]s.

- but what about render priorities?  would it be [gemhead 4 whatever], and would [gemhead whatever] be priority 50?

draft:

 -  each [gemcontrol] is associated with a symbolic name. 

 -  whenever a [gemcontrol] sends a "render"-message to the connected [GemOutput]s, all [gemhead]s with the same name are executed.

what about defaults ?

  the default name of a gem-context is "" (empty string).


i think, all [gemhead]s (regardless of their "name") should be members of the default-context. (note: this is compatible with the old behaviour (well, of course, there was only one window...so compatibility is not a big thing))

i furthermore think, that [gemhead]s with the default name "" should be member of _all_ contexts (probably not, see below)

this should be the most flexible solution.

the only difference (implementation wise) is, that the ordering of the gemhead-list is a bit more complicated. but not much!

example:

  supposed we have 3 [gemcontrol]s ( ![gemcontrol] ![gemcontrol win1] ![gemcontrol vOUT] ) and 3 [gemhead]s ( ![gemhead] ![gemhead win1] ![gemhead win2] )

  - ![gemcontrol] will render ALL [gemhead]s in the pd-instance (![gemhead] ![gemhead win1] ![gemhead win2])

  - ![gemcontrol win1] will render both ![gemhead] and ![gemhead win1]

  - ![gemcontrol vOUT] will render only ![gemhead]


problems:

  how about variable priorities of a [gemhead] for different contexts ?

   solution: i think we can ignore this. a [gemhead] is only associated with 1 (or 2) contexts.
   if we want multiple contexts with different priorities of one gemlist, just connect multiple [gemhead]s to the gemlist.


  how about multiple contexts of one [gemhead] ?

   solution: my initial idea was, that each [gemhead] is associated with the default context and (optionally) with 1 other context.

   but why stay limited to 2 contexts ?

     because it might be hard to control (how to set/change it ?)

   alternative: each [gemhead] is associated with exactly 1 context.
to make a [gemlist] member of multiple contexts, just connect it to multiple [gemhead]s

    problem: we might want to compile a [gemlist] into a display-list; how do we tell several [gemhead]s that the list has to be recompiled ? a display-list should be compiled only once for the different contexts.

    solution: probably split [gemhead] into 2 objects, like ![gemcontext] and ![gemlist], where ![gemcontext] handles the association with a context-name and ![gemlist] handles the compilation of the gemlist

    more: GemCache has to be rewritten anyhow