Hi Michael, On 8/3/07, Michael Ebner <[EMAIL PROTECTED]> wrote: > Could you explain that to me in more detail? I took a quick look at the > GraphicsWindowEmbedded and GraphicsWindowWin32 implementation and this > seems all to be about setting up a window and providing a context to the > Viewer. > The Viewer is handling the threads based on the context(s) provided, so > it should not make a difference if he gets them from embedded or full > blown GraphicsWindow? Or am i missing something here?
To do multi-threading you need control a proper implementation of makeCurrent, releaseContext, without these the various threads can't get access to the graphics context. GraphicsWindowEmbedded doesn't support these as it doens't actually know anything at all about the graphics context, it rather is facade that does nothing but kid osgViewer::Viewer that its OK to go ahead a do rendering on it - but does mean that it can only be used in a constrained way. > I'm using SDL for window and input handling and read in: > http://www.mail-archive.com/[EMAIL PROTECTED]/msg12744.html > > about a GraphicsWindowSDL class, is it going to be submitted to SVN? Personally I wouldn't recommend SDL for windowing for serious 3d graphics applications, its just way too limiting - its really just designed for single threaded, single context apps. I'd recommend using SDL it for cross platform audio and gamepads/joysticks and use the OSG's native Window support to manage windowing. As for implementing a GraphicsWindowSDL, this isn't possible to do because SDL just doesn't expose enough basic windowing functionality to do what a full blown GraphicsWindow requires. I know this because I had a go at writing it when I developed the osgviewerSDL example, I'm afraid I came away with a much lower view of SDL windowing capabilities. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
