[GEM-dev] multiple_window: besides the mouse events...

[Johannes M Zmoelnig]

james tittle wrote:
> On Dec 14, 2004, at 4:24 AM, Johannes M Zmoelnig wrote:
> 
> ...ahhh, you and yr teutonic cleanliness :-)  I don't see any obvious 
> problem to moving that stuff to GemWinCreate***.cpp, but the "devil is 
> always in the details"!  Atm, dispatchGemWindowMessages() is part of 
> [gemwindow], but why can't it be like createGemWindow()?  The only 
> things it needs from the gemwindow class (on OSX) are m_windowClock and 
> m_windowDelTime, I think...

but how to make "GemWinCreate::dispatchWindowMessage()"  output to the 
correct [gemwindow] without having weird callback-trees again.
(most probably i just cannot see it reight now)


> ...a "context" includes all the gl state for a particular offscreen:  
> display-lists, textures, programs, etc...this might be why I'm not 
> seeing anything yet:  I bet that each new window is creating it's own 
> context, and thus has nothing to show outside the last one...

yes, most probably.
so enable display-list sharing ;-)


> ...I was a little surprised to find that there can only be one 
> [gemcontrol]:  I'm not sure how this will help implementing 

oh really ?
right now [gemcontrol] interfaces the static GemMan again.
multiple [gemcontrol] just control the same "GemMan-context". (so if you 
turn on rendering on one [gemcontrol], all others will start rendering too)

> offscreen/pBuffer drawing?  I guess that would be more modeled after 
> [pix_snap2tex]...You once mentioned that if you have 3 windows, with two 
> connected to [gemcontrol] having different views, what would the third 
> one derive from?
nothing, it would be a window that just hangs around.


> 
> ...should it be possible to associate [gemhead]'s with one [gemwindow] 
> and not others?

i don't know, it might be fun; however i see a ton of major problems 
arising with render-order,...........


mfg.as.dr
IOhannes