I'm not sure why you have a thread hung in drawImplementation() after Viewer's destructor has been called. But I can explain some of the other stuff you have questions on, and hopefully that'll help.
> My question is, how do you guys > normally deal with data (scene graph, geometry, text, > whatever) being modified on the main thread while Viewer is > apparently busy rendering the same data? Mark the Node or Drawable as DYNAMIC DataVariance, and only modify it during the update traversal (or outside the rendering traversals). > Having looked at a lot of the other drawables included in > OSG, I don't see how the "double buffering" scheme works -- > how is that any of the scene graph or other geometry data get > updated without creating a race condition like this? OSG operates on a gentleman's agreement under which you can do whatever you want to DYNAMIC nodes during the update traversal, and OSG's possibly multiple threads can perform read-only operations during the cull/draw traversals. With osgViewer-based apps, marking nodes that you intend to modify as DYNAMIC is critical, otherwise OSG might let the update traversal start (or return from frame()) before it has finished processing the node that you're going to modify. > What's the trick here? What > can/can't one do from with the drawImplementation() method in > order to remain thread safe? drawImplementation() should be const, so as long as you don't modify it or anything else in the scene graph, you should be OK. Hope that helps. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
