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

Chris Djali krizdjali at gmail.com
Sun Jun 30 15:57:55 PDT 2019


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







More information about the osg-users mailing list