[osg-users] Dos, Don'ts and DOH's of Drawables with threading?

Paul Martz pmartz at skew-matrix.com
Fri Sep 14 15:46:21 PDT 2007

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

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
303 859 9466

More information about the osg-users mailing list