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