[GEM-dev] "context" with [gemcontrol] or "gemoutput"

[james tittle]

On Feb 4, 2005, at 4:04 AM, IOhannes m zmoelnig wrote:

> james tittle wrote:
>
>> ...but one thing I'm not understanding:  when I have multiple 
>> [gemcontrol]'s, a "render on" message to one turns all of them on:  
>> it seems like this should be seperated, right?  Especially if we're 
>> gonna have the ability to alter the frame rate...
>
> right, it is just not yet implemented... (as it would have involved 
> further changes to GemMan, and i was just happy that at least i got 
> multiple windows rendering (more or less) the same....

...that's ok:  I just didn't know what the status was...

> now what comes to my mind:
>
> should things like background-colour, viewpoint, etc be handled in the 
> GemOutput (as [gemwindow]) or in [gemcontrol] ?
> i always thought they could be handled by GemOutput, but i am not so 
> sure about this anymore (i guess i put it into GemOutput since 
> [gemcontrol] was still static and i wanted to be able to change the 
> viewport on the different windows independently.
>
> i (now) mean that for a clear separation, "context" (again probably 
> missusing this term) details should be handled within [gemcontrol].
> but then we would need some way of synchronizing various independent 
> [gemcontrol]s (e.g. for cave-like applications), probably again by 
> associating the context with a symbolic id (the same as in [gemhead])

...so, this is different than what I first assumed:  when I first got 
this stuff working, I thought that all outputs went to the same 
[gemcontrol], or rather that there would only be one [gemcontrol] per 
patch...but now, I know this is not the case, and my original thoughts 
need to be amended:  fortunately, it seems that most stuff just get 
shifted from the output module "up" to the associated [gemcontrol]

...in this regard, we'd have the possibility of multiple [gemcontrol]'s 
that would would basically take care of everything (ie. background 
color, viewpoint, framerate,...) except for the actual output;  the 
output would would then be the attached [gemwindow], [gemextwindow], or 
[gempbuffer], and all attached outputs would do the same graphic, only 
varying as to which window/screen/offscreen/whatever...

...this moves the earlier idea of symbolic name associations to the 
[gemcontrol], so we'd have a different [gemcontrol] for each unique 
output desired...and [gemhead] stays the same, with both a priority and 
symbolic name association(s)...

...typical rendering would run much the same as it does now, with 
GemMan going thru the gemheadLink list and rendering by priority, then 
passing the created display lists to the correct gemcontrol based on 
their symbol association...

...this all works fine if everything is running at the same framerate, 
but like you pointed out in a later email, what happens if two 
[gemcontrol]'s are running at different frame rates and both pull data 
from the same [gemhead]?

...an easy way around this would be to limit the amount of 
associations:  one [gemhead] can hook/associate with only one 
[gemcontrol]:  if similar [gemhead] functionality is needed for another 
[gemcontrol], then just duplicate the [gemhead] and change it's symbol 
association...

...beyond that, I guess we'd need some universal time keeping mechanism 
above the level of [gemcontrol], or rather as part of GemMan...this 
really makes the mind reel!  I'd have to think alot more, and me head 
hoit!  :-\

hmm,
jamie