...cool! found an easy fix for the triggerMouseEvent() width/height message output for a window...
...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...
...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?
thanx, jamie
james tittle wrote:
...cool! found an easy fix for the triggerMouseEvent() width/height message output for a window...
good to hear.
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)
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...)
not precisely context-sharing but display-list sharing over several contexts (or is this the same thing ?)
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)
mfg.a.sdr IOhannes
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...
...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()...
...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...
...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
james tittle wrote:
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)
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)
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
On Dec 14, 2004, at 1:28 PM, james tittle wrote:
...ok, got around to trying out the shared context thing, and guess what? It works! However, before I commit it I'd like to try it with dual screens, and also do a good bit of cleaning up the macwindow code: it's uuuuuugly...
...so, does this work on windoze? If so, I guess it's about time to merge it into HEAD...
l8r, jamie
On Jan 27, 2005, at 3:11 PM, B. Bogart wrote:
Woo hoo!
...yippee!
...it works by seperating gemwin into a [gemcontrol] that can have several [gemwindow]'s, each of which is then a different "view"...as of now, it's only really good for being able to see what is projected if you can't actually get a line-of-sight, but it's also neat to have multiple view of the same scene, like in a multi-view 3d modeler...
...unfortunately, it doesn't seem to be the solution to make a pbuffer object...that would be more like snap2texture...
...but it's neat anyway... jamie