Hi Rober,
Robert Osfield wrote:
> I've now done a review and believe I understand the motive behind
> resetting the GraphicsThread point to 0 to delete the GraphicsThread,
> this will co-operatively stop this thread safely, and allow the proper
> clean of that graphics context. However, I am concerned that this
> will only work safely for single window applications, for
> multi-context applications there can be a set of threads running in
> the viewer, if we un-laterally destroy one of the threads then we
> introduce the possibility of other threads hanging on barriers that no
> longer have enough threads joining them to release them.
>
Hmmm... I didn't think about this scenario. One thing that I still
haven't been able to wrap my head around is that this problem only
appears when there is a slave camera. To get the problem to happen in
the MFC version of the viewer, you have to turn on stats. In my app, I
either have to turn on stats or my background camera (basically a hud
that's drawn first rather than last) to make the problem happen. I guess
this is why I'm not really comfortable with the diagnosis -- I don't
really understand why the problem doesn't happen for a single camera app.
[ part of your reply has been removed ]
> So peuso code might something like:
>
>
> GraphicsWindow::destroyWindow(..)
> {
>
> ..
>
> if (_graphicsThread && _graphicsThread->isRunning())
> {
> // find all the viewers that might own use this graphics context
> for(each camera on this GraphicsContext)
> {
> osgViewer::View* view =
> dynamic_cast<osgViewer::View*>(camera->getView());
> osgViewer::ViewerBase* viewerBase = view ? view->getViewerBase() :
> 0;
> if (viewerBase && viewerBase->areThreadsRunning())
> viewerBase->stopThreading();
> }
>
> }
>
> ...
> }
>
Would it be helpful for me to test this idea with my app and the mfc viewer?
Sorry for the slow responses. I'm moving in a week and sorting through
and culling all the junk I've accumulated has been taking all of my
time. It's a bit refreshing to be getting rid of so much stuff though.
Cory
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
