...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)
...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...)
...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 ?)
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:
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
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
On Dec 14, 2004, at 1:28 PM, james tittle wrote:
...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()...
...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
Woo hoo!
How does it work? (second argument to gemwin for rendering context?) Does it also work to render to a pbuffer to be textured in another chain?
I'm exited to see this...
B.
...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
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
On Jan 27, 2005, at 3:11 PM, B. Bogart wrote:
Woo hoo!
...yippee!
How does it work? (second argument to gemwin for rendering context?) Does it also work to render to a pbuffer to be textured in another chain?
...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
-
B. Bogart -
james tittle -
Johannes M Zmoelnig