So, if I parsed your message correctly, such a barrier as I require doesn't currently exist and I would need to modify the code to add it.
Seems like, to maximize benefit from these two threading models, I should have as many STATIC nodes as possible, and only switch to DYNAMIC when necessary. So providing such a barrier would be useful. As a semi-related follow-up, if I've added a GUIEventHandler to a viewer, can I assume that handle() gets called only after renderingTraversals() has returned? Thanks, -Paul > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Robert Osfield > Sent: Sunday, April 15, 2007 2:57 AM > To: osg users > Subject: Re: [osg-users] Blocking until draw completes > > Hi Paul, > > The sync is done entirely withing the > Viewer::renderingTraversals() method, so that this method > does complete untill the block is released by the cull/draw > threads. This applies to all threading models. > > Not requiring external sync is something I've gone for with > osgViewer to simplify the usage of it, and to make single > threading and multi-threaded usage more consistent and easy > to use. One doesn't need to worry about doing sync, and > avoiding writing to the scene graph outside of when > renderingTraversals() is running. > > The only exception to this is the DrawThreadPerContext and > CullThreadPerCameraDrawThreadPerContext threading models that > allow the draw threads to run in parallel with the update and > cull threads, by returning early once all dynamic objects are > drawn. Using these threading models one does have to be > careful about modifying DataVariance and modifying STATIC > state and drawables, and here one would need to pause till > all drawing is done. To do this one will need to insert a > Barrier into the GraphicsThreads for each active context, and > block on this barrier in the main thread. > > Now getting your hards dirty with Barrier's is an advanced > topic, one that osgViewer encapsulates for normal usage so > you never need to worry about it. Perhaps osgViewer could go > further and help in this particular type of usage, and be > tweaked so that you can turn on the Barrier for a frame, or > perhaps have a renderingTraversal() method that allows you to > turn on such a barrier. > > Robert. > > On 4/14/07, Paul Martz <[EMAIL PROTECTED]> wrote: > > > > > > Hi Robert -- A while back we had an exchange about how the new > > threading model that runs update in parallel with draw > would require > > that an application have to block until after the draw completes > > before the app could modify a node marked as STATIC. > > > > I looked in both osgViewer::Viewer and osg::Camera but > couldn't figure > > out what call I should make that would block until after the draw > > traversal completes. Can you give me more detail on how I > should do this? > > > > Thanks, > > > > Paul Martz > > Skew Matrix Software LLC > > http://www.skew-matrix.com > > 303 859 9466 > > > > _______________________________________________ > > osg-users mailing list > > [EMAIL PROTECTED] > > http://openscenegraph.net/mailman/listinfo/osg-users > > http://www.openscenegraph.org/ > > > _______________________________________________ > osg-users mailing list > [EMAIL PROTECTED] > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [EMAIL PROTECTED] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
