For contents of the render graph, the following might have some information:
http://www.bricoworks.com/articles/stateset/stateset.html
http://www.bricoworks.com/articles/stategraph/stategraph.html
SingleThreaded means that frame() doesn't return until the draw threads have
completed. At that time, you are free to make any changes you want. In other
threading models, the draw threads might still be active after frame() returns,
but you are guaranteed that objects with dynamic data variance have been
processed (only static or unspecified data variance is left for the draw threads
to work on).
The update NodeVisitor is for convenience only and isn't required for any
modifications.
If your instability (crash?) goes away in SingleThreaded mode, then the issue is
either improper use of data variance, or you have a thread safety issue in one
of your callbacks.
-Paul
On 2/20/2012 7:49 AM, Eric Pouliquen wrote:
Thanks Paul for your answer.
You're right, the conservative approch is a good way to think, as it seems to
be very critical (seeing from stability of the app).
I was wondering effectively what is or not in the render graph, just because it
seems it can affect a lot the global perf of the app...
Just a little question: Is right to tell that this Dynamic datavariance has no effect in
"SingleTreaded" mode ?
I'm digging my code because I have instabilities and it always crashes on the
"frame()" function of the viewer...
Last but not least, in the same way of thinking, I wonder since a long time of what NEED
to be in an updateCallback... for example, when you change a switch state, or a stateset
value .. ? Maybe you will answer the same way... the conservative approch is to put every
modification in an updatecallback, but I just wonder. If on of these chages is not
correctly coded in such a callback, can it causes crash or only a "one frame"
update latency ?
Thanks again
Eric
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=45603#45603
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
