[GEM-dev] musings on multiple_window

[james tittle]

On Feb 2, 2005, at 3:46 AM, IOhannes m zmoelnig wrote:

> james tittle wrote:
>> heya,
>> ...so, cgc and I chatted last nite, and I'm wondering if it's 
>> plausible
>
> men, where do you do it ?

...hacked hotline server ("underline") with crypto:  it was late...I 
have been poking in to #dataflow, so maybe we should set up a time?  
Or, I can try to log in earlier...

>> to add another symbol to gemhead for gemman to manage...the priority 
>> system would still be used for rendering order, but the new symbol 
>> would be used to determine which output/glcontext the render would go 
>> to (kinda like pd's send/receive objects):  by default (ie. no extra 
>> symbol), output would go to the "main" gemwindow...if there is a 
>> symbol, then the output would go to the associated display output:  
>> so we'd need to add a symbol to each gemoutput:
>> [gembuffer offscreen1]:  this would be for pBuffer
>> [gemwindow onscreen1]:  this would be for primary display
>> [gemdv onscreen2]:  this would be a dv stream of the onscreen2 render
>> [gemwindow onscreen2]:  this would be for 2nd monitor display
>
> i would rather associate the "context" with the [gemcontrol] object.

...if you prefer "context" over "output", I was talking about them as 
the same thing (by context I mean the gl environment, which at the 
moment is just associated with windows)

>> ...then the gemheads would be something like the following:
>> [gemhead 43 offscreen1]:  this then renders to a pBuffer
>> [gemhead -1 onscreen1]:  this renders to the primary display
>> [gemhead -2 onscreen2]:  this renders to the 2nd monitor
>> ...we'd then need the output [gembuffer offscreen1] to allow binding 
>> to texture for texturing on objects, which could then perhaps be 
>> rendered into another buffer, textured, then rendered into a scene 
>> for screen display...
>
> that is exactly how i imagined it !

...yeah!  Althought it could mean we're all crazy...

> just one remark: the ordering of the context-name and the priority 
> should be arbitrary:
> eg: [gemhead 10 offscreen]
> [gemhead blur] (==[gemhead 50 blur])
> [gemhead bibs 32]
> ...

...no problem there, but I was thinking it'd be easier for backwards 
compatibility if we kept an ordering of priority then context name:  if 
we can manage backwards compat. with arbitrary ordering, even better!

> and probably "main" (or rather "") is attached to all contexts, like
>
> [gemcontrol] context ""
> [gemcontrol offscreen] context "offscreen"
> [gemcontrol ot] context "ot"
>
>
> [gemhead] renders to "", "offscreen", "ot"
> [gemhead ot] renders to "", "ot"

...yes, this is ok, but it may get confusing:  how do we define which 
is the "main"/"" context?  The first one created?  The last one in the 
priority chain (because everyone would be rendered prior to it)?

> and do we want to be able to connect one [gemhead] to multiple 
> explicit contexts ?
>
> like [gemhead here there everywhere]

...yep, this'd be good...

>> ...any obvious problems?
>
> yes, timing.
> i guess it would/could/should be possible to somehow handle 
> [gemcontrol]s at different rates, e.g. only render once a second into 
> a pbuffer (or even better: on demand!)
>
> how do we handle this efficiently ? (esp. with respect to "time-based" 
> objects, like [pix_movie] in auto-mode or particle-systems)

...have to admit I haven't looked much at this, but I will:  what are 
the likely situations that could trip us up?

...otoh, couldn't we duplicate what is done now i pix_film?  I mean, 
it's possible atm to run one film in auto-mode, and another in 
metro/"by-the-frame" mode:  wouldn't this be our solution?

...another thought to take us further:  glGenTextures() and 
glGenPrograms() both return unique id's for their association:  I think 
these should also be globally accessible, perhaps by symbol or patch 
connection...this would be useful for manipulating the different 
texture units for multitexturing, plus it allows us to load a vertex or 
fragment program once into memory and continuously refer to it as 
needed, rather than loading the whole program every frame...

whew,
jamie