On Thu, Oct 16, 2008 at 2:42 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> HI Csaba,
>
> I suspect the particular problem you are seeing is not directly driver
> related, but is an OSG bug, differences in drivers might change the
> timing slightly which leads to the problem not becoming visible, but
> may well still be lurking.

Hi Robert,

Huh, took me two days, but I think I have traced this to a race condition.
Apparently the _endDynamicDrawBlock was already reached by a graphics
thread before the viewer got a chance to reset it.
So then that draw thread was released (and subsequently blocked on the
sceneview queue) and the viewer has gone to infinite wait on the
_endDynamicDrawBlock later.
This simpe patch (that doesn't even hint at how difficult it is to
trace such bugs) seems to fix the issue here:

Index: src/osgViewer/ViewerBase.cpp
===================================================================
--- src/osgViewer/ViewerBase.cpp        (revision 9034)
+++ src/osgViewer/ViewerBase.cpp        (working copy)
@@ -674,14 +674,14 @@

     bool doneMakeCurrentInThisThread = false;

-    // dispatch the the rendering threads
-    if (_startRenderingBarrier.valid()) _startRenderingBarrier->block();
-
     if (_endDynamicDrawBlock.valid())
     {
         _endDynamicDrawBlock->reset();
     }

+    // dispatch the the rendering threads
+    if (_startRenderingBarrier.valid()) _startRenderingBarrier->block();
+
     // reset any double buffer graphics objects
     for(Cameras::iterator camItr = cameras.begin();
         camItr != cameras.end();

I am not even sure why the _endDynamicDrawBlock has to be reset. Comments?

-- 
Csaba
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to