[GEM-dev] musings on multiple_window

[james tittle]

Hey ben,

On Feb 2, 2005, at 12:57 PM, B. Bogart wrote:
> I've not had a chance to play with your binary distro, but I'm 
> certainly exited about the prospect. Indeed I am also more interested 
> in managing multiple windows with different contents, rather than 
> running multiple instances of Gem to control two windows with 
> different contents.

...this is a good point:  with multiple machines running independent 
instances of GEM, you can certainly do something similar to what we're 
working on...this may still be necessary for some projects (we all know 
that computers can usually only do just under what we want!)...

> so [gemwindow onscreen1] would create a new window context with the 
> symbol name "onscreen1" then gemhead 1 "onscreen1" would render only 
> to this nammed context?
> I think this is a great solution in Gem, certainly quite intuitive.

...exactly...

> (what do the negative render-priorities in your examples do?)

...this stems from IOhannes saying "hmm, if we use an integer to 
represent 1 to 100, what are we going to do with the unused negative 
numbers?"...negative render-priorities are rendered after the positive 
ones, so it kinda goes like this:

- set up viewport/angle
- we proceed 1 to 100 (actually don't know if 100 is just an arbitrary 
end or not?)
- reset viewport/angle
- proceed -100 (again, don't know if -100 is an arbitrary beginning?) 
to -1
- end of render

...may be useful, maybe not...

> This functionality is really making me drool. :)

...(spittoons not provided)...

> so would we also name each gemcontrol object to bind it to a 
> particular window's symbol? Would we use gemcontrol to say, colour the 
> background colour of a pbuffer, the way we colour the background of a 
> window?

...depends on what functionality is built in to the gemoutput:  atm, 
[gemwindow] responds to the same messages that [gemwin] used to...I 
image many of same commands would work the same for a pbuffer, but some 
wouldn't (can't understand why we'd want to respond to [border <, 
[offset <, etc)...

> It would be nice to tell a gemhead to render on a particular context 
> but also a set of them [gemhead 1 onscreen1 onscreen2] but I would say 
> this is probably not needed, since I think most people would want to 
> tell objects to render to some specific window, not a group of them. 
> I'm sure there is some great creative use for having this feature 
> though.

...I agree that we'll usually just associate most gemheads with one 
output, but we always try not to limit ourselves in gem 
functionality/flexibility...it may be necessary to accept multiple 
contexts if we restrict asset accesses thru a namespace mechanism...or 
if we introduce "un-shared" contexts...

> How does the timing work now with multiple-windows? Are they all 
> locked into the same framerate? The only reason I could see needing 
> different frame-rates for each window would be if you wanted to save 
> CPU usage on your personal "preview" window when rendering at 60fps on 
> the second screen... Otherwise I think it would be fine to lock all 
> windows to the same framerate. (I could be misunderstanding the timing 
> issue here).

...again, flexibility is paramount!  But, [gemcontrol] handles the 
frame rate message, so all outputs associated with it would have the 
same frame rate...as it is right now, that means all windows have the 
same frame rate, because right now you can only have one 
[gemcontrol]...

...this brings up something I hadn't thought about earlier:  on osx, 
pbuffer creation depends on a pixel format compatibility with the 
current context...this makes me tend to think that buffers might need 
to be associated with a certain display...but then, if we're doing 
everything in a shared-context situation (as we are), this shouldn't be 
an issue...

> I'm going to download the test binary now...

...cool!  I always look forward to your new screenshots:  I'm trying to 
play with gem more than code, but it's hard not to code!

jamie