[osg-users] Dos, Don'ts and DOH's of Drawables with threading?
acoates at stanford.edu
Fri Sep 14 18:04:33 PDT 2007
Excellent - that was all the explanation I needed. Everything is
humming along just fine now.
On 9/14/07, Paul Martz <pmartz at skew-matrix.com> wrote:
> 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
> osg-users mailing list
> osg-users at lists.openscenegraph.org
More information about the osg-users