[osg-users] How can we make 'osg' thread and 'ui' thread send messages to each other?
Hi, How to solve the problem with UI Thread conflict Thank you! Cheers, Mirro -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76346#76346 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
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
Re: [osg-users] Removing objects with shared GL state from scene graph
HI Chris, On Sun, 30 Jun 2019 at 19:28, Chris Djali wrote: > > Are you seriously telling me that OpenSceneGraph provides no mechanism to > safely remove nodes that at one point were attached to the scene graph and > this is intentional? If so, it's misleading to even have functions like > osg::Group::removeChild as they're providing unsupported behaviour. I'd be > very surprised if this is actually what you're saying. > I'm not saying that at all. The limitation with the current design+implementation is you hold a global reference to a scene graph object to prevent it from getting deleted normally as it's hidden from the viewers that manage the graphics contexts. For those objects you have to explictly call releaseGLObjects() as it won't happen for you. Now, if this mechanism isn't working for a particular non standard usage case then it could be that the above extra house keeping isn't being done correctly, or there's an underlying OSG bug that needs to be addressed. At this point I think it's pointless trying to explain yet again as that "I don't really understand what you mean", I've read what you've written multiple times tried my best and given you my best answer. The best way to sort out this type of issue is by creating an example that illustrates the problem usage case. The one you've posted has problems that I raised, these would need fixing before taking the next step and looking to whether there is an OSG bug. It's also important to test against OSG-3.6 branch/master as well as whatever other versions you are building against. There was a bug in handle osgText in 3.4.x that was addressed in 3.6.x. Cheers. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, I still think you're completely missing my point because of a criticism of my example code. For now, ignore the symptoms that brought me here. Just consider your bog-standard single-viewer situation. If a text node is added to the scene graph and stays attached for the whole lifetime of the viewer, everything is fine. If two text nodes are added to the scene graph and stay attached for the whole lifetime of the viewer, everything is fine. If a text node is added to the scene graph and is removed before the viewer is destroyed, you can either not release GL objects, and have a bunch of things leak, or release them, and have everything be fine. If you have two text nodes in the scene graph, and one is removed before the viewer is destroyed, you can either not release GL objects, and have some things leak (and some get cleaned up), or release them, and break the still-attached node. Are you seriously telling me that OpenSceneGraph provides no mechanism to safely remove nodes that at one point were attached to the scene graph and this is intentional? If so, it's misleading to even have functions like osg::Group::removeChild as they're providing unsupported behaviour. I'd be very surprised if this is actually what you're saying. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76343#76343 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi Chris, On Sun, 30 Jun 2019 at 00:52, Chris Djali wrote: > The high-level behaviour is all fine as-is. The specific problem is that > it's not safe to call osgText::Text::releaseGLObjects when removing a text > object as that releases GL objects for the font, too, and that can still be > in use by other text nodes. > It should be safe to call Text/Font::releaseGLObjects(state) with the deletion of GraphicsContext that the state associated with that GraphiscContext, that's the intention, if that isn't working and the high level functionality is working correctly then this is a bug. I've just done a quick review of the code and master and 3.6 branch do mostly seem to be doing what they should in the Text/Font::releaseGLObjects(). There is one area that does look like it might be missing some releaseGLObjects() calls is in the handling of Glyph3D objects. However, in your example where you were playing games with globals to prevent destruction, this remains the wrong way to implement viewers and is not supported by the relaseGLObjects() scheme, for reasons I've outlined in my replies above. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
