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 wrote:
> Hi,
>
> Hopefully this example illustrates the underlying problem with
> osgText::Text::releaseGLObjects without the multiple viewer schenanigans in
> my previous example:
>
>
> Code:
>
> #include
> #include
> #include
> #include
>
>
>
> 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 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 font =
> osgText::readRefFontFile("trebuc.ttf");
>
> osg::ref_ptr text1 = new osgText::Text();
> text1->setFont(font);
> text1->setText("text1");
> scene->addChild(text1);
>
> osg::ref_ptr 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@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
