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 gemheads are associated with the according gemcontrols.

• 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 GemOutputs, all gemheads with the same name are executed.

what about defaults ?

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

i think, all gemheads (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 gemheads 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 gemcontrols ( [gemcontrol] [gemcontrol win1] [gemcontrol vOUT] ) and 3 gemheads ( [gemhead] [gemhead win1] [gemhead win2] )

• [gemcontrol] will render ALL gemheads 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 gemheads 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 gemheads

problem: we might want to compile a gemlist into a display-list; how do we tell several gemheads 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