Hi Paul, On Fri, Apr 18, 2008 at 10:18 AM, Paul Melis <[EMAIL PROTECTED]> wrote: > Looking at that example I see that swapbuffers has to be called manually > in this case, but I fail to find the place in the source where Viewer > checks if it is running embedded and therefore doesn't have to call > swapbuffers itself. Can you give a hint where this is?
osgViewer::Viewer/CompositeViewer don't check to see if the graphics window is an embedded one, they just assume its not, and go ahead and call makeCurrent and swapBuffers on the graphics window. In the case of GraphicsWindowEmbedded these are non ops, since they nothing about the actual graphics context, only the app does they can't do anything but non ops. This does sound like a bit of recipe for disaster... but, as long as the app is running the viewer with single context and single threaded and does the makeCurrent and swapBuffers as required in its own code everything works. GraphicsWindowEmbedded is really just a an adapter that fools osgViewer into behaving more like osgUtil::SceneView, just a far more capable version that supports events, event handlers, camera manipulators, database paging, all with the same API as the fullblown osgViewer base apps. This makes it much simpler to migrate to a full scalable OSG app just a few code changes in the client app. On of the key points about osgViewer is the ability to unify a full range of usage models all within the same set of classes, this makes providing a consistent set of API and functionality across the usage range, and make it easier to move between different usage styles, and for me it makes it easier to maintain, document and support. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
