<div dir="ltr"><div dir="ltr">Hi Chris,<br></div><br><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.  <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">--</div><div class="gmail_quote"><br></div><div class="gmail_quote">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().<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Robert.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div></div>