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