Hi Robert, >> What happens when you move across to a screen on a different graphics card? >> The fact that it works at all is slightly encouraging, perhaps it is >> just an issue of the graphics context OpenGL current state getting >> corrupted and a osg::State::reset might get the OSG to reapply things >> - perhaps this could be called in a custom >> GraphicsWindowWin32::resizeImplementation(); >> Note that under OSX Stephan has had to add a update call to make sure >> that the graphics context hangs together on a resize. Dragging a >> window will also produce a resizedImplementation call so perhaps could >> be reused for the same tweaks.
I'll try sticking another graphics card in my dev machine to see what happens... >> If its what you have to do, then you have to do it... The only thing >> I'd add is the importance of being able to cleanly kill the thread on >> exit - we need to keep in mind then people will be open and closing >> graphics windows and viewers, and even unloading the OSG libraries >> completely and then reloading them later. >> OK I'm a bit confused now, what exactly are these display devices that >> aren't attached to the desltop? Are they bona-fida outputs such as >> that you can attach a monitor or projector to? Or are you talking >> just pbuffers or unmapped windows? Under Windows each display adapter can be attached to the desktop (participating in the Windows virtual screen spanning across all attached devices) or left unattached. When unattached the window manager is unable to use it, so no window can be created on its surface. Pretty much the only thing you can do with unattached devices is to create a device context on them and then use GDI to draw into them. It remains to be seen if OpenGL is able to render into such context. Bottom line is that if this does not work or is too cumbersome to make work, the workaround (very simple) is just to have the user attach all display adapters to the desktop so the window manager can use all of them. This really is just an annoyance and a very minor issue in my opinion. >> On the topic of pbuffers, I haven't tackled the GraphicsContextX11 >> implementation yet, I'm expecting a number areas where they will be >> opportunities for sharing code between the GraphicsWindowX11 and the >> GraphisContextX11, but how to take advantage of this is the challenge. >> What I certainly don't want to do is mix up the derivation of >> GraphicsContext and GraphicsWindow, these need to be kept separate, a >> pbuffer is just a graphics context and all the window functions >> present on GrpahicsWindow implementation are inapprorpriate - and you >> don't want end users dynamic_cast<GraphicsWindow> on pbuffers to find >> this succeeding - So the pbuffer X11 implementation shoudln't subclass >> from GraphicsWindowX11. Also GraphicsWindowX11 can't inherit from >> GraphicsContextX11 and GraphicsWindow, unless you start playing games >> with virtual inhertance of GraphicsContext. >> So I'm wondering if a X11 helper class might be in order to help >> manage the common elements between the GraphicsContextX11 and >> GraphicsWindowX11. This approach could also apply to what approach to >> take under Windows and OSX so I'd suggest hanging back of pbuffer work >> till I have a bash at pbuffer support under X11, see what leasons I >> learn and what bits of the general framework I need to tweak to get >> things to play nicely together. OK. André PIXDEV inc. [EMAIL PROTECTED] _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
