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

[james tittle]

On Dec 14, 2004, at 4:24 AM, Johannes M Zmoelnig wrote:
>
> looking through the code i have noticed that for too many (in my 
> opinion) os-specific lines are in [gemwindow]
> probably it would really be best to move _all_ of the os-specific code 
> into GemWinCreate***.cpp (that what these files are for at last)
> admittedly the __linux__ share in gemwindow.cpp (or formerly 
> GemMan.cpp) is by far the biggest, as all the event-handling stuff is 
> in there.
>
> but what would be the best way to get the mouse-callbacks right then ? 
> (i mean, the event-callback-system is somewhat different on all 
> platforms)

...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...


>> ...so, tonight I got the multiple_window branch to compile and run on 
>> OSX, but it's not running quite completely...so far it will create 
>> new windows (and apparently gl contexts) for each [gemwindow] object, 
>> and I have them hooked up to a [gemcontrol]. but only the last one 
>> created actually displays anything...
> weird, i remember having had similar problems in the beginning, but 
> they disappeared after several re-compiles (probably i did change 
> something but i don't remember any more...)

...I'm not sure if it's a compile/link-order problem (like I often had 
with pix_film/pix_video inheritance), or if it's a problem of not 
creating windows with shared contexts?  It'd be nice if it were the 
former, but I strongly suspect it's the latter...

...if indeed it's the shared context-problem, then we'll need to 
somehow pass along the previous context's info to createGemWindow()...

>> ...have to admit that, beyond getting it to compile and all, I 
>> haven't really gone deeply thru the code to check out context sharing 
>> and such:  is this working on xwindows atm?
>
> not precisely context-sharing but display-list sharing over several 
> contexts (or is this the same thing ?)

...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...

> but that might be the problem with you displaying too:
> the whole scene is compiled into a display-list when the first window 
> issues the GemMan::render(); all the following windows only execute 
> this display-list.
> this has advantages (like the use of display lists; or simply that 
> only one "render trigger" is send through the network per cycle) and 
> also some disadvantages (might be slower when only one context is 
> used, display-list sharing must be enabled)

...hmm:  I'll have to look into this and see if I can find out how 
other programs do multiple windows and views and such (and also read up 
on display lists in general)...

...I was a little surprised to find that there can only be one 
[gemcontrol]:  I'm not sure how this will help implementing 
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?

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

back to work,
jamie