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