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

[Robert Osfield]

Hi Chris,

I have begun reviewing the test program.  In the comments you suggest if
relaseGLObects() isn't call text1 objects leak.  This confuses me, what
"objects" do you think leak? At this point I need something concrete to
investigate.

FYI, delete texture and other GL objects are cached in set of GL objects
that are queued for deletion (for textures it's the TextureObjectManager
that does this), the deletion of GL obejcts has to happen in a thread that
has the context current that owns those GL objects, so there is a call to
osg::flushDeletedGLObjects(..) in the draw traversal by sceneView.  The
containers that manage the list of GL objects to be deleted can also cache
them for reuse - this is done for textures, so when you create a new
texture and there is a texture object that has be queued for deletion then
rather than delete and create the OSG is able to simple reuse the texture
object avoiding the expensive delete and create texture object calls.

This reuse feature is crucial for paged databases and defaults of how many
texture objects to keep around are chosen for typically hardware and data
so there shouldn't normally be any need to worry about, the OSG should
mostly just do the right thing.  If you are concerned that texture objects
etc. are getting cleaned up as soon as you'd expect then you can setting
the TextureObjectManager properties (see the include/osg/Texture header for
details), there is one TextureObjectManager per graphics context.

--

In your test program you have scene graph objects that you explicitly
retain ref_ptr<>'s to, which will mean these objects won't get deleted
until the exit of the main.  This makes me wonder if perhaps the perception
of leak could be down to just the ordering of things are done.  For this
particular usage case it seems to me like everything should just work out
of the box without any need to explicitly call releaseGLobjects().

I currently don't know what to investigate, there isn't anything too
unusual in this example that makes me think there is some usage case where
the usual OSG mechanisms might fail, it looks pretty straight forward to
me.  I've already done a heap load of bug hunting and fixing in this area
prior to 3.6, with much more challenging usage.  Since I don't know what
specially you think is leaking and I don't have any hunches myself I'll
just have to wait till you give more guidance.

Robert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20190702/9519cadd/attachment.html>