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