[osg-users] Removing objects with shared GL state from scene graph

[Robert Osfield]

Hi Chris,

I have spent the day merging submissions, I have a bit more to do, then
I'll see if I can recreate the bug with your latest test program, if I
don't get to it today, I'll have a bash tomorrow before I head away for a
family break.  What versions of the OSG have you tested with this test
program?  What versions of the OSG should I expect to see problems?

Cheers,
Robert.

On Mon, 1 Jul 2019 at 03:02, Chris Djali <krizdjali at gmail.com> wrote:

> Hi,
>
> Hopefully this example illustrates the underlying problem with
> osgText::Text::releaseGLObjects without the multiple viewer schenanigans in
> my previous example:
>
>
> Code:
>
> #include <osg/AutoTransform>
> #include <osgGA/TrackballManipulator>
> #include <osgText/Text>
> #include <osgViewer/Viewer>
>
>
>
> int main()
> {
>     osgViewer::Viewer viewer;
>     // Single-threaded mode so we don't need to worry about things still
> being used by the draw traversal
>     viewer.setThreadingModel(osgViewer::ViewerBase::SingleThreaded);
>
>     // Use an auto transform so the text actually faces the screen
>     osg::ref_ptr<osg::AutoTransform> scene = new osg::AutoTransform();
>     scene->setAutoRotateMode(osg::AutoTransform::ROTATE_TO_SCREEN);
>     viewer.setSceneData(scene);
>
>     // Add two text nodes sharing the same font
>     osg::ref_ptr<osgText::Font> font =
> osgText::readRefFontFile("trebuc.ttf");
>
>     osg::ref_ptr<osgText::Text> text1 = new osgText::Text();
>     text1->setFont(font);
>     text1->setText("text1");
>     scene->addChild(text1);
>
>     osg::ref_ptr<osgText::Text> text2 = new osgText::Text();
>     text2->setFont(font);
>     text2->setText("text2");
>     scene->addChild(text2);
>
>     // Display one or more frames
>     viewer.setCameraManipulator(new osgGA::TrackballManipulator());
>     for (int i = 0; i < 100; ++i)
>         viewer.frame();
>
>     // Remove a text node
>     scene->removeChild(text1);
>
>     // Pick which path depending on whether we prefer leaks or rebuilding
> things we're still using and potential errors
>     if (true)
>     {
>         text1->releaseGLObjects();
>         // text2 must now compile its program again -
> osg::Program::compileGLObjects is called the next frame.
>         // Also, the glyph texture (which text2 still needs) is added to
> the pending orphaned texture list.
>         // I'm not sure how OSG would normally delete orphaned textures,
> so I can't trigger that, but I imagine OSG doesn't keep them all around
> forever.
>     }
>     else
>     {
>         // text2 can still use its program and the glyph texture, but
> text1's objects leak.
>     }
>
>     text1 = nullptr;
>
>     return viewer.run();
> }
>
>
>
>
> All that happens here is we create a viewer, add two text nodes with the
> same font, and 100 frames later, remove one of them again. The text node
> that remains has to recompile its shader program (a very minor but
> unnecessary performance hit) and its glyph texture ends up in the orphaned
> texture list (which I'm pretty sure means it could be deleted at any time).
>
> If I knew how OSG typically cleans up orphaned textures, I could add extra
> steps to this and make it actually produce OpenGL errors when the texture
> is deleted, but as-is it just hangs around in the orphaned list
> indefinitely.
>
> Cheers,
> Chris
>
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=76345#76345
>
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20190701/825005f1/attachment.html>