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

[Robert Osfield]

Hi Chris,

On Tue, 3 Sep 2019 at 18:08, Chris Djali  wrote:

> It's been a week, so I'm just checking this hasn't been forgotten.
>

Not forgotten, but I'm working flat out to get database paging
functionality into the VSG right now so don't have time or spare brain
capacity to go chasing other topics.  The time I had available to work on
the was July, during my holiday, now an OSG work has to be squeezed in when
I'm not work on intense stuff.

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

[Chris Djali]

Hi,

It's been a week, so I'm just checking this hasn't been forgotten.

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76638#76638





___
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

[Robert Osfield]

Hi Chris,

Thanks for the test program.  I've created a CMake file and got it
compiling and running on my Linux system.  I tweaked the window creation so
it uses a multiple windows on a single screen as that suits by desktop
configuration better.  On pressing 'V' multiple times I get the white text
and GL errors reported on the second time the extra view creation happens.

I've put debugging code into the Registry and Renderer to see if my
addition to Renderer::releaseGLObjects() was working and found that when
the view gets removed this isn't called.  However, if I press escape and
the both view+windows get deleted then the Renderer::releaseGLObjects()
gets called.  I don't know why this isn't working as intended yet.

I have other work to get on with today so I'll need to return to
investigating this later, my guess is that we just need to tighten up the
handling of the removeView.

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

[Chris Djali]

Hi,

The reason I couldn't add or remove views during the event traversal was that 
it was invalidating iterators that iterated over the views. Instead, I'm adding 
an update operation to add or remove the viewer.

I now have a fairly minimal example that replicates my use case and bug:


Code:

#include 

#include 

#include 

#include 

#include 

class AddViewOperation : public osg::Operation
{
public:
AddViewOperation(osg::ref_ptr view)
: osg::Operation("AddView", false)
, _view(view)
{}

void operator() (osg::Object * compositeViewer) override
{
OSG_NOTICE << "AddView operator()" << std::endl;
osgViewer::CompositeViewer * viewer = 
dynamic_cast(compositeViewer);
viewer->stopThreading();
viewer->addView(_view);
viewer->startThreading();
}

protected:
osg::ref_ptr _view;
};

class RemoveViewOperation : public osg::Operation
{
public:
RemoveViewOperation(osg::ref_ptr view)
: osg::Operation("RemoveView", false)
, _view(view)
{}

void operator() (osg::Object * compositeViewer) override
{
OSG_NOTICE << "RemoveView operator()" << std::endl;
osgViewer::CompositeViewer * viewer = 
dynamic_cast(compositeViewer);
viewer->stopThreading();
viewer->removeView(_view);
viewer->startThreading();
}

protected:
osg::ref_ptr _view;
};

class ViewAdder : public osgGA::GUIEventHandler
{
public:
ViewAdder(osgViewer::CompositeViewer * viewer)
: _viewer(viewer)
, _view(nullptr)
{}

bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa)
{
if (ea.getEventType() == osgGA::GUIEventAdapter::KEYUP && (ea.getKey() 
== 'v' || ea.getKey() == 'V'))
{
if (_view)
{
OSG_NOTICE << "Existing view, remove it" << std::endl;
// parts of the scene get removed before the view gets 
destroyed.
// normally this is fine as things get handled by destructors.
// however, things that are still cached require the cache to 
be released
_view->setSceneData(nullptr);
// We need to remove the view after the event traversal is done 
to avoid invalidating iterators
_viewer->addUpdateOperation(new RemoveViewOperation(_view));
_view = nullptr;
}
else
{
OSG_NOTICE << "No existing view, create one" << std::endl;
_view = new osgViewer::View;
_view->setName("View two");

_view->setUpViewOnSingleScreen(1);


osg::ref_ptr text2 = new osgText::Text();
text2->setText("Here's some other text. It appears in the 
dynamically-added view. It ensures the default font gets used with a context 
that goes away, and that lives in the cache.");
osg::ref_ptr autoTransform2 = new 
osg::AutoTransform();

autoTransform2->setAutoRotateMode(osg::AutoTransform::ROTATE_TO_SCREEN);
autoTransform2->addChild(text2);
osg::ref_ptr scene2 = autoTransform2;

_view->setSceneData(scene2.get());
_view->setCameraManipulator(new osgGA::TrackballManipulator);

_viewer->addUpdateOperation(new AddViewOperation(_view));
}
return true;
}
return false;
}

protected:
// raw pointer because it's stack-allocated
osgViewer::CompositeViewer * _viewer;
osg::ref_ptr _view;
};

int main(int argc, char **argv)
{

// use an ArgumentParser object to manage the program arguments.
osg::ArgumentParser arguments(, argv);

osg::ref_ptr text = new osgText::Text();
text->setText("Here's some text. It doesn't have to be text, and in fact we 
don't need anything in the main view as it just exists to keep the application 
alive.");
osg::ref_ptr autoTransform = new osg::AutoTransform();
autoTransform->setAutoRotateMode(osg::AutoTransform::ROTATE_TO_SCREEN);
autoTransform->addChild(text);
osg::ref_ptr scene = autoTransform;

if (!scene)
{
OSG_NOTICE << argv[0] << ": requires filename argument." << std::endl;
return 1;
}

// construct the viewer.
osgViewer::CompositeViewer viewer(arguments);

// single-threaded to prove a threading bug isn't responsible for the 
symptoms
viewer.setThreadingModel(osgViewer::CompositeViewer::SingleThreaded);

// view one
{
osg::ref_ptr view = new osgViewer::View;
view->setName("View one");
viewer.addView(view);

view->setUpViewOnSingleScreen(0);
view->setSceneData(scene.get());
view->setCameraManipulator(new osgGA::TrackballManipulator);

view->addEventHandler(new ViewAdder());
}

// run the viewer's main frame loop
return viewer.run();
}





This started life as the Composite 

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

[Chris Djali]

Hi,

I'm trying to build a stripped-down version of the same behaviour as my 
application, but it's got extra issues because things that are handled by what 
I'm stripping out aren't being handled when they're gone.

What's the correct process for adding and removing views to and from an 
osgViewer::CompositeViewer while it's running? I was under the impression I 
just needed osgViewer::CompositeViewer::stopThreading and 
osgViewer::CompositeViewer::startThreading either side of it being added and 
removed, but that's not working (access violation) when doing it with an 
osgGA::GUIEventHandler attached to one of the views. There's pretty much 
nothing else at all in the demo application, just a text node added to all of 
the views.

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76610#76610





___
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

[Robert Osfield]

Hi Chris,

As far as I'm aware the issues you have are pretty unusual, in most usage
cases the OSG looks to be doing the right thing, it's niche usage cases
that are the issue.  I've tried to help plug the gaps with the usage cases
you've come up with, but can't do anymore without concrete usage cases to
study that illustrate in runnable code the problem you have, trying to
parse explanations for this type of thing is fraught with problems - what
might be clear in your head but you have a whole bunch of extra information
relevant to your application that I don't have.  I have lots of different
topics that need my attention so I have to jump between, each one I have to
try to get up to speed and work out what is going on, having threads that
meander across months of posts makes this whole process even harder to
follow.

Concrete code cuts through it all, a succinct example that I can read work
out what is going on, run it, see the problem first hand, then apply and
fix and confirm that it fixes it.  It's the gold standard way to get things
resolved.

On Sat, 24 Aug 2019 at 01:18, Chris Djali  wrote:

> The diff that fixes my use case is
> >...
> How does this look to you?
>

Looks like a hack that would be workaround for a specific usage case not a
general solution.

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

[Chris Djali]

Hi,

As we've discussed, that only occasionally helps. In the boring single-viewer, 
single-view case, it works, but no one would notice there was a problem there 
anyway as nothing would actually render incorrectly.

My application just uses the camera created for it by OSG when an 
osgViewer::View is created, and I think it's reasonable to expect OSG to clear 
up things it's created itself. I'm under the impression that you do, too.

I've been having a poke around, and it seems to me that one possible option 
would be to call releaseGLObjects on a camera being removed from an 
osg::GraphicsContext when it's the only one attached. In such a situation, we 
already call it on the camera's non-shared child nodes (which is all of them) 
and its rendering cache, so this only adds the renderer and callbacks as extra 
things being released. It's my belief that this could only cause unwanted 
releasing in the case where all the cameras were removed from a context and 
then new ones were added. I think such a situation is probably unlikely (but 
you'd know better) and not much would be different to how things are now, as 
any attached nodes are already being released. There's also an added bonus that 
the function can return early as there'd be no need to work out which child 
nodes may or may not be shared.

The diff that fixes my use case is

Code:

diff --git a/src/osg/GraphicsContext.cpp b/src/osg/GraphicsContext.cpp
index 1a35497d0..e6113eb9a 100644
--- a/src/osg/GraphicsContext.cpp
+++ b/src/osg/GraphicsContext.cpp
@@ -741,6 +741,12 @@ void GraphicsContext::addCamera(osg::Camera* camera)

 void GraphicsContext::removeCamera(osg::Camera* camera)
 {
+if (_cameras.size() == 1 && camera == _cameras.front())
+{
+_cameras.clear();
+camera->releaseGLObjects(_state.get());
+return;
+}
 Cameras::iterator itr = std::find(_cameras.begin(), _cameras.end(), 
camera);
 if (itr != _cameras.end())
 {




How does this look to you?

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76605#76605





___
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

[Robert Osfield]

Hi Chris,

On Wed, 21 Aug 2019 at 20:18, Chris Djali  wrote:

> Is the plan still to have OSG itself release GL objects in the object
> cache when the contexts they're associated with are destroyed, and if so,
> have you had any further thoughts about how this might be accomplished?
>
> The problem is still that there's nothing in osgViewer that has the same
> lifetime as an osg::GraphicsContext, and osg isn't supposed to be aware of
> osgDB, so it has to be osgViewer that releases things, right?
>

I have already added a
osgDB::Registry::instance()->releaseGLObjects(state); to the
osgViewer::Renader::releaseGLObjects():


void Renderer::releaseGLObjects(osg::State* state) const
{
osgDB::Registry::instance()->releaseGLObjects(state);

if (_sceneView[0].valid()) _sceneView[0]->releaseGLObjects(state);
if (_sceneView[1].valid()) _sceneView[1]->releaseGLObjects(state);
}

This is in master and the 3.6 branch.  This should clear the ObjectCache.
It's why I added this.

I can't keep running around in circles on this.  I've put in a lot of
effort to try and resolve what I can, but now I need to get on with other
work.

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

[Chris Djali]

Hi,

Is the plan still to have OSG itself release GL objects in the object cache 
when the contexts they're associated with are destroyed, and if so, have you 
had any further thoughts about how this might be accomplished?

The problem is still that there's nothing in osgViewer that has the same 
lifetime as an osg::GraphicsContext, and osg isn't supposed to be aware of 
osgDB, so it has to be osgViewer that releases things, right?

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76601#76601





___
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

[Robert Osfield]

Hi Chris,

I read that post but didn't reply as I couldn't see anything that required
any feedback from myself.

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

[Chris Djali]

Here it is again:


AnyOldName3 wrote:
> Hi,
> 
> Hopefully, after that two-week hiatus, we can get this sorted.
> 
> 
> > You can always subclass from Camera and override the destruct if you want 
> > to add this "fix" if it suits your usage case. 
> 
> 
> I'm already going to have to include a separate fix for older OSG versions 
> (and I have a good idea of how I'll implement it), as we're supposed to 
> support as far back as 3.4.x, so if we're abandoning the idea of actually 
> fixing the issue in OSG itself, I've already got a workaround figured out.
> 
> I imagine, though, that until everyone who writes applications knows how to 
> use Vulkan and all devices have Vulkan support, removing the footgun from OSG 
> is still your preferred option.
> 
> 
> > The approach I have taken with the VSG is for the GPU objects to hold a 
> > ref_ptr<> to the VkInstance wrapper preventing it being deleted when the 
> > objects are still in use.  It's thread safe, robust for a lots of different 
> > usage cases and straight forward.  Alas OpenGL can't be managed like this, 
> > or at least I don't think you can keep a graphics context around after a 
> > window has been deleted.  If I was to writing an OpenGL scene graph from 
> > scratch I'd probably try to resolve this topic in a more flexible way than 
> > the OSG which has evolve from narrower usage cases to more and more general 
> > usage cases as users have pushed and pulled it in various directions. 
> 
> 
> That does sound like a much nicer way of doing things. The only thing similar 
> I can think of with OpenGL is to have a sharing context with access to the 
> same objects as the main window, and to only destroy this extra context once 
> everything has been released, but then I'm still discovering surprising new 
> OpenGL features that can do new things.
> 
> Cheers,
> Chris


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76598#76598





___
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

[Robert Osfield]

Hi Chris,

On Mon, 19 Aug 2019 at 22:58, Chris Djali  wrote:

> Did my last message disappear because of the forum issues? It's been a
> while and there's no reply yet...
>

How should we know if what your last message was if it might have
disappeared :-)

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

[Chris Djali]

Hi,

Did my last message disappear because of the forum issues? It's been a while 
and there's no reply yet...

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76596#76596





___
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

[Robert Osfield]

Hi Chris,

On Fri, 26 Jul 2019 at 17:46, Chris Djali  wrote:

> This does solve the problem. Is it definitely safe it do this, though?
> What if the camera references stuff still shared by another context (e.g.
> RTT cameras that get added to and removed from an existing context)? I
> don't imagine you want to add a regression while fixing this.
>

O bugger, good point, yep lucky it didn't make it into 3.6.4 :-)

This issue is like juggling with a dozen different ball, with each ball
being a different usage case!

You can always subclass from Camera and override the destruct if you want
to add this "fix" if it suits your usage case.

The approach I have taken with the VSG is for the GPU objects to hold a
ref_ptr<> to the VkInstance wrapper preventing it being deleted when the
objects are still in use.  It's thread safe, robust for a lots of different
usage cases and straight forward.  Alas OpenGL can't be managed like this,
or at least I don't think you can keep a graphics context around after a
window has been deleted.  If I was to writing an OpenGL scene graph from
scratch I'd probably try to resolve this topic in a more flexible way than
the OSG which has evolve from narrower usage cases to more and more general
usage cases as users have pushed and pulled it in various directions.

For now I'll need to focus on getting my BOF presentation written rather
than bug fixing, it's end of the working here in Scotland so I'm in weekend
mode too and not about to try to think too hard about anything other than
chilling wit my family.

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

[Chris Djali]

Hi,


> So... would change the destructor to: 
> 
> 
> Camera::~Camera() 
> { 
> setCameraThread(0); 
> 
> if (_graphicsContext.valid()) 
> 
> { 
>releaseGLObjects(_graphicsContext->getState()); 
> 
> 
> _graphicsContext->removeCamera(this); 
> } 
> else 
> { 
> releaseGLObjects(); 
> 
> } 
> 
> 
> } 


This does solve the problem. Is it definitely safe it do this, though? What if 
the camera references stuff still shared by another context (e.g. RTT cameras 
that get added to and removed from an existing context)? I don't imagine you 
want to add a regression while fixing this.


Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76507#76507





___
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

[Robert Osfield]

Hi Martin,

On Fri, 26 Jul 2019 at 11:41, Martin Siggel 
wrote:

> Hi Robert,
>
> I had a custom camera manipulator, which was derived from orbitmanipulator.
>
> I experienced the issue in my Android app. I assigned this manipulator to
> the osgviewer and kept a reference outside of the viewer. My idea was to
> keep the current state of orbit animation and position when going back to
> the app.
>
> However, this prevented cleaning up all the GL objects from the current
> context, even though I deleted the viewer. After removing the reference to
> the manipulator, everything worked as expected.
>

Using an osg::observer_ptr<> might be the best solution for this type of
usage.


> Therefore, I suppose that there has to be some reference to the camera in
> the manipulator.
>

There isnt' any need to have an explict link to the Camera as the higher
level functionality passes in the
CameraManipulator::updateCamera(osg::Camera& camera) method.  This means
it's possible to use the same CameraManipulator with multiple Camera i.e.
have multiple View's but each share the same CameraManipualator.


> I could provide an example but it will be an Android example. Is there
> something you could use?
>

I don't have a Android setup yet so such an example won't help too much.
In your case I think it's just more careful management of objects that is
required rather than a bug in the core OSG that needs to be resolved.

This whole issue stems from a limitation with OpenGL and how you can only
do clean up from a graphics thread associated with graphics context, and
once a window closes it's graphics context is no longer valid so any
handles you have to the objects held in that context are now invalid.  This
means you have to juggle who and when gets to clean up the gl objects and
the handle to them.

In the Vulkan/VSG the objects are mostly associate with a device context
rather than a window so it's possible to have windows come and go and still
manage the lifetime of the objects in a straight forward way.  Or at least
I've been able to hide the lifetime issue in a far easier and more robust
to different usage cases way.  On the OSG side it's usage cases on the
edges of the usual way that the OSG does things is when problems arise.

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

[Martin Siggel]

Hi Robert,

I had a custom camera manipulator, which was derived from orbitmanipulator.

I experienced the issue in my Android app. I assigned this manipulator to
the osgviewer and kept a reference outside of the viewer. My idea was to
keep the current state of orbit animation and position when going back to
the app.

However, this prevented cleaning up all the GL objects from the current
context, even though I deleted the viewer. After removing the reference to
the manipulator, everything worked as expected.

Therefore, I suppose that there has to be some reference to the camera in
the manipulator.

I could provide an example but it will be an Android example. Is there
something you could use?

Martin

Robert Osfield  schrieb am Fr., 26. Juli 2019,
12:31:

> Hi Martin,
>
> On Fri, 26 Jul 2019 at 11:12, Martin Siggel 
> wrote:
>
>> Yes, it's the standard manipulator. I am not sure though, if it keeps a
>> direct reference or an indirect reference (via other nodes) to the camera.
>>
>> Still I noticed, if I keep a reference to the camera manipulator my
>> viewer is not cleaned up correctly.
>>
>
> I'm afraid I'm not able to parse the above.  Do you have a ref_ptr<> to
> the camera manipulator in your application outside of the View/Viewer
> handle to it?  What CameraManipulator are you using?
>
> Could you create a small example to illustrate this usage case?  I've been
> reviewingan testing all the CompositeViewer/View and associated examples
> today but haven't yet come across an example of usage case they is causing
> the problems.
>
> Robert.
>
> Robert.
>
>
>
>
> ___
> 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

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

[Robert Osfield]

Hi Martin,

On Fri, 26 Jul 2019 at 11:12, Martin Siggel 
wrote:

> Yes, it's the standard manipulator. I am not sure though, if it keeps a
> direct reference or an indirect reference (via other nodes) to the camera.
>
> Still I noticed, if I keep a reference to the camera manipulator my viewer
> is not cleaned up correctly.
>

I'm afraid I'm not able to parse the above.  Do you have a ref_ptr<> to the
camera manipulator in your application outside of the View/Viewer handle to
it?  What CameraManipulator are you using?

Could you create a small example to illustrate this usage case?  I've been
reviewingan testing all the CompositeViewer/View and associated examples
today but haven't yet come across an example of usage case they is causing
the problems.

Robert.

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

[Martin Siggel]

Yes, it's the standard manipulator. I am not sure though, if it keeps a
direct reference or an indirect reference (via other nodes) to the camera.

Still I noticed, if I keep a reference to the camera manipulator my viewer
is not cleaned up correctly.

Robert Osfield  schrieb am Fr., 26. Juli 2019,
11:49:

> Hi Martin,
>
> On Fri, 26 Jul 2019 at 09:45, Martin Siggel 
> wrote:
>
>> I observed, that also CameraManipulators keep a reference to the camera.
>> This prohibits then the release of the gl objects.
>>
>
> Which CameraManipulator do you think keeps a reference to the Camera?
> I've just checked and can't find any.
>
> The StandardManipulator currently has a ref_ptr< osg::Node > , could this
> be what you are thinking of?
>
> Robert.
>
>
> ___
> 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

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

[Robert Osfield]

Hi Martin,

On Fri, 26 Jul 2019 at 09:45, Martin Siggel 
wrote:

> I observed, that also CameraManipulators keep a reference to the camera.
> This prohibits then the release of the gl objects.
>

Which CameraManipulator do you think keeps a reference to the Camera?  I've
just checked and can't find any.

The StandardManipulator currently has a ref_ptr< osg::Node > , could this
be what you are thinking of?

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

[Robert Osfield]

Hi Chris,

On Fri, 26 Jul 2019 at 00:38, Chris Djali  wrote:

> I have more information. The GraphicsContext is only referenced by the
> camera when the camera is destroyed. The camera detaches itself from the
> graphics context in its destructor, then the camera's ref_ptr to the
> graphics context is destroyed, triggering the destruction of the graphics
> context. The graphics context calls its own close in its destructor, but by
> then the camera has already detached itself, so it's not helpful.
>

I don't recall the reason for the current form of the Camera destructor,
it's current incarnation is:

Camera::~Camera()
{
setCameraThread(0);

if (_graphicsContext.valid()) _graphicsContext->removeCamera(this);
}

So if the GraphicsContext hasn't already been closed then the removeCamera
above would prevent the releaseGLObjects() being called on the Camera.

So... would change the destructor to:

Camera::~Camera()
{
setCameraThread(0);

if (_graphicsContext.valid())
{
   releaseGLObjects(_graphicsContext->getState());

_graphicsContext->removeCamera(this);
}
else
{
releaseGLObjects();
}
}

Work for your usage case?

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

[Chris Djali]

Hi,

I have more information. The GraphicsContext is only referenced by the camera 
when the camera is destroyed. The camera detaches itself from the graphics 
context in its destructor, then the camera's ref_ptr to the graphics context is 
destroyed, triggering the destruction of the graphics context. The graphics 
context calls its own close in its destructor, but by then the camera has 
already detached itself, so it's not helpful.

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76497#76497





___
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

[Chris Djali]

Hi,


> Are the Camera's being removed from the Window before it gets closed?  I have 
> just checked the GraphicsContext::close() method and it calls all the 
> Camera::releaseGLObjects(), which in turn will call the 
> Renderer::releaseGLObjects(), which will now call the 
> ObjectCache::releaseGLObjects().  After calling all the releaseGLObjects() 
> the GraphicsContext::close() then calls the 
> osg::deleteAllGLObjects(_state->getContextID())  of the context isn't shared.


There aren't any cameras in the GraphicsContext's list when its 
closeImplementation is called. The camera is removed from that list by its 
destructor, and its destructor is called when the ref_ptr is set to zero in the 
osg::View destructor.

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76496#76496





___
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

[Robert Osfield]

Hi Chris,

I've reviewed the CompositeViewer::addView()/removeView() and then both
look fine, for the general case I don't see anything obvious that needs
adding.  Calling releaseGLObjecs() isn't something I would add to
removeView() as you can have multiple views sharing the same window and
sharing the same scene graph so if you did call releaseGLObjects() you only
have to recreate them.  If the View has a GraphicsWindow/GraphicsContext of
it's own when the window gets closed it should be able to do the clean up
then.

Would there be any value in making CompositeViewer::addView/removeView()
virtual?  So you can subclass from CompositeViewer and override them?

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

[Robert Osfield]

Hi Chris,

On Thu, 25 Jul 2019 at 17:33, Chris Djali  wrote:

> Annoyingly, while that branch fixes the issue in my examples, it isn't
> fixing it in my actual application.


I guess that's an improvement :-)

This change is in the OpenSceneGraph-3.6 branch and the 3.6.4-rc9 so will
part of the release.


> The cache gets cleared when the application exits (potentially after all
> OpenGL contexts have been closed), but not when views are added to and
> removed from the composite viewer, so I'm still getting the same Warning:
> detected OpenGL error 'invalid value' at after RenderBin::draw(..) message.
> I'm not seeing Renderer::releaseGLObjects get called ever, but I can't tell
> whether it would be called if there was a view active when the application
> was closed, as I'm also battling a Qt bug that causes a crash in that
> situation.
>

Are the Camera's being removed from the Window before it gets closed?  I
have just checked the GraphicsContext::close() method and it calls all the
Camera::releaseGLObjects(), which in turn will call the
Renderer::releaseGLObjects(), which will now call the
ObjectCache::releaseGLObjects().  After calling all the releaseGLObjects()
the GraphicsContext::close() then calls the
osg::deleteAllGLObjects(_state->getContextID())  of the context isn't
shared.

There might be something weird that needs fixing at my end. I can see with
> tracepoints that a pair of Renderers gets constructed when the application
> constructs a View and StatsHandler and they get destroyed when the last
> ref_ptr to the view is destroyed, so the Renderers aren't sticking around
> forever.
>

I don't have your application or test app with similar behavior so can't
add much more.

With the Qt error, it could be that the OSG integration or the OSG itself
isn't doing something perfectly for this usage case so the problem pops in
Qt, it could also be just a Qt bug...

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

[Chris Djali]

Hi,

Annoyingly, while that branch fixes the issue in my examples, it isn't fixing 
it in my actual application. The cache gets cleared when the application exits 
(potentially after all OpenGL contexts have been closed), but not when views 
are added to and removed from the composite viewer, so I'm still getting the 
same Warning: detected OpenGL error 'invalid value' at after 
RenderBin::draw(..) message. I'm not seeing Renderer::releaseGLObjects get 
called ever, but I can't tell whether it would be called if there was a view 
active when the application was closed, as I'm also battling a Qt bug that 
causes a crash in that situation.

There might be something weird that needs fixing at my end. I can see with 
tracepoints that a pair of Renderers gets constructed when the application 
constructs a View and StatsHandler and they get destroyed when the last ref_ptr 
to the view is destroyed, so the Renderers aren't sticking around forever.

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76493#76493





___
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

[Robert Osfield]

A the commit with the changes:


https://github.com/openscenegraph/OpenSceneGraph/commit/83b74e4a02cbdcf965040e67d7d12bb21fdac2cf
___
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

[Robert Osfield]

The branch with the experiment is:

   https://github.com/openscenegraph/OpenSceneGraph/tree/RegistryRelease
___
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

[Robert Osfield]

Hi Chris,

To experiment with different approaches to doing the releaseGLObjects()
call management I have created a RegistryRelease branch of the
OpenSceneGraph that is branched off the OpenSceneGrpaph-3.6 branch.  This
branch just contains a single commit so far that wraps up:

  1) Chnage of osgText::DefaultFont to use the osgDB::ObjectCache assigned
to the osgDB::Registry::instance() rather than a local static
ref_ptr

  2) Change of osgViewer::Renderer::releaseGLObjects(State*) so that it
calls the osgDB::Registry::instance() that will in turn
  call the osgDB::ObjectCache::releaseGLObjects(State*) which will in
turn
  call DefaultFont::releaseGLObjects(State*)

  3) Debug console output to track the creation, destruction and calls to
releaseGLObjects() of the various players above.

I've done some testing here to confirm that the
DefaultFont::relaseGLObjects() is now being called, but I don't have you
application usage case to thoroughly hammer it. So... I really need you to
test it at your end.  If this works better then I can clean it up and get
it checked into the OpenSceneGraph-3.6 branch and master.

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

[Robert Osfield]

Hi Chris,

I will have a look at the Font issue today, see if there is any
improvements that might be possible in the 3.6 branch.  The release of the
context and object cache would only be possible with high level management
as osg::Context doesn't know about osgDB due to the hierarchy of libs.

This close to a release I can't make any major changes though, so I might
not be able do very much.

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

[Chris Djali]

Hi,

Now Robert seems to be back from his break, I'm just going to mention the 
potential footguns I found here in case they need sorting out. I've got a 
reasonable solution for the issue I was having, so that doesn't really need 
discussing any more, but it seems sensible to me that OSG might want to avoid 
letting people get into such a situation in the first place.

When a context is destroyed, the object cache can still have things in 
it that need releasing. It might be a good idea to automatically release things 
in the object cache when a context is destroyed. Even in the single-view case, 
it's not best practice to rely on the GPU driver to clean up everything when a 
context is closed, so this might be helpful for anything that loads stuff from 
files.

If a composite viewer has a cleanup operation, it's only called when 
the composite viewer is destroyed, and not when associated contexts are 
destroyed. This should maybe be changed so that it happens when a view is 
removed, too, or maybe it should be possible to set a cleanup operation on the 
context objects themselves.

The static default font doesn't get released when a context is 
destroyed. I don't know everything about OSG, so maybe there's a list of static 
OSG objects that it should be added to, or maybe having static OSG objects is 
just a bad idea.



Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76471#76471





___
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

[Chris Djali]

Hi,

Now Robert seems to be back from his break, I'm just going to mention the 
potential footguns I found here in case they need sorting out. I've got a 
reasonable solution for the issue I was having, so that doesn't really need 
discussing any more, but it seems sensible to me that OSG might want to avoid 
letting people get into such a situation in the first place.

When a context is destroyed, the object cache can still have things in 
it that need releasing. It might be a good idea to automatically release things 
in the object cache when a context is destroyed. Even in the single-view case, 
it's not best practice to rely on the GPU driver to clean up everything when a 
context is closed, so this might be helpful for anything that loads stuff from 
files.

If a composite viewer has a cleanup operation, it's only called when 
the composite viewer is destroyed, and not when associated contexts are 
destroyed. This should maybe be changed so that it happens when a view is 
removed, too, or maybe it should be possible to set a cleanup operation on the 
context objects themselves.

The static default font doesn't get released when a context is 
destroyed. I don't know everything about OSG, so maybe there's a list of static 
OSG objects that it should be added to, or maybe having static OSG objects is 
just a bad idea.



Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76470#76470





___
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

[Robert Osfield]

Hi Chris,

I'll have a look at the leads you've detailed on my return next week,

Cheers,
Robert.

On Thu, 4 Jul 2019 at 10:42, Chris Djali  wrote:

> Hi,
>
> Turns out that it's not a font in the object cache that's causing me grief
> after all, but instead the static default font here:
> https://github.com/openscenegraph/OpenSceneGraph/blob/OpenSceneGraph-3.6/src/osgText/Font.cpp#L40.
> This is initialised from a GLubyte array instead of a file, so never ends
> up in the object cache.
>
> I can manually call releaseGLObjects on it when a graphics context is
> destroyed, which solves the problem for my application, but I can provide
> an example of an OSG application that CodeXL says leaks stuff to prove that
> there's still a footgun.
>
>
> Code:
> int main()
> {
> osgViewer::Viewer viewer;
>
> // 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);
>
> osg::ref_ptr text1 = new osgText::Text();
> text1->setText("text1");
> scene->addChild(text1);
>
> // 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 or not we trust all references
> to things to go away
> if (false)
> {
> text1->releaseGLObjects();
> }
> else
> {
>
> }
>
> text1 = nullptr;
>
> // osgText::Font::getDefaultFont::s_defaultFont still exists, so the
> default font isn't released
>
> return viewer.run();
> }
>
>
>
> As before, CodeXL is still reporting the following error:
>
> [Image:
> https://cdn.discordapp.com/attachments/502999428798480387/596112745104146487/unknown.png
> ]
>
> Maybe it would be a good idea for static OSG objects to all be held
> together in a global vector somewhere so that their GL objects can be
> released whenever a context is destroyed. Maybe something like that exists
> already and the default font just got forgotten.
>
> Cheers,
> Chris
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=76365#76365
>
>
>
>
>
> ___
> 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

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

[Chris Djali]

Hi,

Turns out that it's not a font in the object cache that's causing me grief 
after all, but instead the static default font here: 
https://github.com/openscenegraph/OpenSceneGraph/blob/OpenSceneGraph-3.6/src/osgText/Font.cpp#L40.
 This is initialised from a GLubyte array instead of a file, so never ends up 
in the object cache.

I can manually call releaseGLObjects on it when a graphics context is 
destroyed, which solves the problem for my application, but I can provide an 
example of an OSG application that CodeXL says leaks stuff to prove that 
there's still a footgun.


Code:
int main()
{
osgViewer::Viewer viewer;

// 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);

osg::ref_ptr text1 = new osgText::Text();
text1->setText("text1");
scene->addChild(text1);

// 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 or not we trust all references to 
things to go away
if (false)
{
text1->releaseGLObjects();
}
else
{

}

text1 = nullptr;

// osgText::Font::getDefaultFont::s_defaultFont still exists, so the 
default font isn't released

return viewer.run();
}



As before, CodeXL is still reporting the following error:

[Image: 
https://cdn.discordapp.com/attachments/502999428798480387/596112745104146487/unknown.png
 ]

Maybe it would be a good idea for static OSG objects to all be held together in 
a global vector somewhere so that their GL objects can be released whenever a 
context is destroyed. Maybe something like that exists already and the default 
font just got forgotten.

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76365#76365





___
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

[Chris Djali]

Hi,

Apparently, that approach won't work here - in my actual application, the 
multiple views are managed with a composite viewer, and that only calls its 
cleanup operation in its destructor and not when views are removed. I'll still 
be able to make something work, but it would have been nice to just set a 
callback that gets called right before a context is destroyed.

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76362#76362





___
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

[Chris Djali]

Hi,

This surprises me, but apparently clearing the object cache is enough to stop 
anything from leaking (otherwise, in the case where the second text node was 
removed, too, without releasing its GL objects, CodeXL was reporting two leaked 
shaders and three leaked program pipelines). I was expecting some things not to 
be released by their destructors, but apparently everything is.

I'm now in a situation where I think I can solve the issue that's bothering me 
sufficiently tidily that it won't be a maintanance nightmare, so the OpenMW 
Construction Set might be about to get its first non-nasty piece of code, which 
is nice.

I've seen that the object cache also has a releaseGLObjects function, which I 
imagine should have roughly the same effect except with the option to do it for 
just one context instead of all of them. I'm planning on calling that as part 
of a viewer cleanup operation. Might it be an idea to make this happen 
automatically in OSG without applications having to set it up themselves?

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76361#76361





___
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

[Robert Osfield]

Hi Chris,

On Tue, 2 Jul 2019 at 15:43, Chris Djali  wrote:

> If that's the case, though, it seems like relying on it for correctness
> isn't a good strategy - surely all these release calls exist because
> there's some chance an implementation detail might change at some point and
> make them necessary.
>

I don't yet get the leak part.  The Font class manages all of it's objects
via ref_ptr<>, they all will be deleted automatically once the Font get
deleted.

Is it simply that the Font's that are cached within the osgDB::ObjectCache
that is keeping Font's around independent of the scene graph objects that
are coming and going.

You can explicitly flush the ObjectCache.

Again, what makes you think there is a leak, are you using some debug tool
to determine this? If so, which one?

I am still at the point of not knowing whether it's a usage issue at your
end, a mis-understanding of how things work, or a bug in the OSG.  From the
info I have so far I don't have way of knowing, which is why I'm asking
specifically about the leak.

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

[Chris Djali]

Hi,

When the text node's releaseGLObjects is called, it calls the same method of:
The 
GlyphQuads
The 
Font (which is potentially problematic when it doesn't get skipped).
The vertex attributes (
_coords, _normals, _colorCoords, _texcoords)
The primitives in 
_decorationPrimitives
The base 
Drawable.

The Text destructor releases none of these, neither does the TextBase 
destructor, and the Drawable destructor doesn't release everything that its 
releaseGLObjects does, but that might be inconsequential.

The GlyphQuads should be fine as it's just its primitives that get released, 
and all the primitive sets seem to release their own stuff in their 
destructors. It should be similar for _decorationPrimitives.

The vertex attributes might be fine with the handling in their destructors, too.

As I've been saying, the font might be shared with other text nodes, so may or 
may not be released later depending on what happens with other text nodes.


That means that it's possible that within all the nested releasing of GL 
objects for a text node, only the font actually owns anything that needs 
releasing, so in the case where only one text node is removed, we get away 
without calling releaseGLObjects.

If that's the case, though, it seems like relying on it for correctness isn't a 
good strategy - surely all these release calls exist because there's some 
chance an implementation detail might change at some point and make them 
necessary.

It also isn't a great strategy to apply generally - if we removed all the text 
nodes, and didn't release the last one, the texture and program(s) the font 
owns would definitely leak. In the case of an application where for whatever 
reason it's difficult to keep track of which text node is the last, and so a 
consistent strategy is required, you're back with the release-or-leak choice.

Surely the best solution is an osgText::Text::releaseGLObjects implementation 
that's always safe to call for text nodes that won't get used again?

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76357#76357





___
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

[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.
___
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

[Chris Djali]

Hi,

I've only tested that example against the 3.6 branch (as of commit 4b6d9287, 
which was the latest yesterday), and while it doesn't actually crash or show 
errors, putting tracepoints in shows that the shader program is recompiled and 
the glyph texture is added to the orphaned list once the text node is removed 
after a hundred frames.

It should break more visibly if you add something to flush the orphaned texture 
list.

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76350#76350





___
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

[Robert Osfield]

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

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

[Chris Djali]

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

[Robert Osfield]

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

[Chris Djali]

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

[Robert Osfield]

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

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

[Chris Djali]

Hi,

I've been putting off responding to the last post as I wanted to be sure I 
wasn't misunderstanding you, but after several rereadings, I still think you've 
missed my point. I'll try explaining the issue again, but I'm not sure which 
part isn't clear, so I don't know how much it'll help.

In the application I'm working with, many viewers (and their OpenGL contexts) 
can come and go over the lifetime of the program, but the scenegraph doesn't 
get replaced, so can be used with multiple viewers, potentially at the same 
time.

OSG has mechanisms that make this work, such as how osg::Program has 
PerContextProgram. Most of the time, this works just fine - provided you 
release a node's GL objects when you remove it from the scene, and let a viewer 
release the GL objects it has in the scene when you destroy it, everything is 
managed correctly.

However, osgText::Text doesn't work well with this approach. It uses one 
osg::Program for all instances in the scene that have the same font, so it's 
not safe to release a text node's GL objects when you remove it, as they may 
still be being used by another text node. Unless you've got a hacky workaround 
in place (a few of which I've outlined above), the shared program will leak 
when the viewer is destroyed (which is bad) and then, if another viewer is 
assigned the same context ID (which it will be), it's mistaken for the old one, 
and the invalid PerContextProgram (which refers to the leaked GL program) gets 
used, causing OpenGL errors.

This might have wider-reaching consequences than just the issue I'm having in 
the lots-of-viewers case - if two text nodes with the same font are used and 
one gets deleted, regardless of whether more contexts are created later:
calling 
osgText::Text::releaseGLObjects calls osgText::TextBase::releaseGLObjects, 
which calls osgText::Font::releaseGLObjects, releasing GL objects still in use 
by the other text node.
Not calling 
osgText::Text::releaseGLObjects means that the other GL objects the node owns, 
such as its vertex buffers, get leaked, even though the shared font might get 
cleaned up later with the other text node.


Maybe the right thing to do is to only release the font's GL objects when all 
its users request it, rather than just one. I've not thought of a nice way of 
implementing this yet.


I'll address specific parts of the previous post now:


> there is no mechanism for deleting
> this global prior to the viewer cleans up so in essence it's prevent
> that scene graph from being deleted and cleaned up. After the exit of
> the main frame loop you could explicitly delete this object.


There's not supposed to be any mechanism for deleting it prior to the viewer 
cleaning up as it's going to be used by another viewer later. Pretend it's not 
just a few ShapeDrawables with labels, but instead something really complicated 
that takes a long time to regenerate.


> Another
> approach would be to make this World object a custom Group node in the
> scene graph that adds the high level behaviors you want and with it
> ensure that you can override any releaseGLObjects() etc on any locally
> cached objects that would otherwise be hidden from the OSG's attempts
> at cleaning things up.


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.

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76341#76341





___
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

[Robert Osfield]

On Thu, 16 May 2019 at 00:07, Chris Djali  wrote:
> It looks like this has fallen off the radar again as it's been a month. I'd 
> still rather fix this in a robust way rather than making a guess as to the 
> most sensible approach and creating maintenance problems down the line.

Sorry, I've been submerged in VSG work.

Just now I had a quick scan of your test program but haven't compiled
and run it.  My first though is the global World object holds a
ref_ptr<> to the scene graph and there is no mechanism for deleting
this global prior to the viewer cleans up so in essence it's prevent
that scene graph from being deleted and cleaned up.  After the exit of
the main frame loop you could explicitly delete this object.  Another
approach would be to make this World object a custom Group node in the
scene graph that adds the high level behaviors you want and with it
ensure that you can override any releaseGLObjects() etc on any locally
cached objects that would otherwise be hidden from the OSG's attempts
at cleaning things up.

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

[Chris Djali]

Hi,

It looks like this has fallen off the radar again as it's been a month. I'd 
still rather fix this in a robust way rather than making a guess as to the most 
sensible approach and creating maintenance problems down the line.

Thank you!

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76109#76109





___
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

[Chris Djali]

Hi,

The following basically simulates the use case that's causing problems.


Code:
#include 

#include 
#include 
#include 
#include 

#include 

#include 

/** A representation of something that gets edited.
 *  Pretend it's actually more complicated than this so that reference counting 
the number of attached text nodes is a nuisance. */
class World
{
public:
World() : mScene(new osg::Group)
{
// add things so the viewer doesn't automatically zoom too far in to 
see the 'objects'

auto worldCorners = { osg::Vec3(-11, -11, -11), osg::Vec3(-11, -11, 11),
  osg::Vec3(-11, 11, -11), osg::Vec3(-11, 11, 11),
  osg::Vec3(11, -11, -11), osg::Vec3(11, -11, 11),
  osg::Vec3(11, 11, -11), osg::Vec3(11, 11, 11) };

for (auto corner : worldCorners)
{
osg::ref_ptr pat = new 
osg::PositionAttitudeTransform();
pat->setPosition(corner);
pat->addChild(new osg::ShapeDrawable(new osg::Sphere(osg::Vec3(0, 
0, 0), 0.1)));
mScene->addChild(pat);
}
}

osg::ref_ptr getScene() { return mScene; }

/** Adds an object with a label to the scene based on something the user 
has done. */
void addObject(std::string name)
{
osg::ref_ptr object = new 
osg::PositionAttitudeTransform();
object->setName(name);

static std::random_device r;
static std::default_random_engine randEngine(r());
static std::uniform_real_distribution<> dist(-10, 10);

object->setPosition(osg::Vec3(dist(randEngine), dist(randEngine), 
dist(randEngine)));

osg::ref_ptr objectLabel = new osgText::Text();
osg::ref_ptr autoTransform = new 
osg::AutoTransform();
autoTransform->addChild(objectLabel);
autoTransform->setAutoRotateMode(osg::AutoTransform::ROTATE_TO_SCREEN);
object->addChild(autoTransform);
autoTransform->getOrCreateStateSet()->setMode(GL_DEPTH_TEST, 
osg::StateAttribute::OFF);
objectLabel->setText(name);
objectLabel->setCharacterSize(1);

osg::ref_ptr shape = new osg::Sphere(osg::Vec3(0, 0, 0), 1);
object->addChild(new osg::ShapeDrawable(shape));

mScene->addChild(object);
}

/** Removes an object from the scene based on something the user has done. 
*/
void removeObject(std::string name)
{
osg::ref_ptr child;
for (unsigned int i = 0; i < mScene->getNumChildren(); ++i)
{
if (mScene->getChild(i)->getName() == name)
{
child = mScene->getChild(i);
mScene->removeChild(i);
break;
}
}

// If we call child->releaseGLObjects() here, the text program will be 
released, too, even though it could still be being used by other labels.
// If we don't, we may be detaching the last text node from the scene 
graph, and so the text program may never get released.
}

private:
osg::ref_ptr mScene;
};


World world;
bool useNewViewer = true;

class EventHandler : public osgGA::GUIEventHandler
{
public:
bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa)
{
if (ea.getEventType() != osgGA::GUIEventAdapter::KEYDOWN)
return false;

// The user may wish to close the 3D view to work on something else and 
then reopen it later.
// That would be a pain to implement directly, so instead, we simulate 
it by reopening the 3D view when it's closed if Return was pressed while it was 
open.
if (ea.getKey() == osgGA::GUIEventAdapter::KEY_Return)
{
useNewViewer = true;
return true;
}
// Press a letter key without shift to add an object.
else if (ea.getKey() >= 'a' && ea.getKey() <= 'z')
{
std::string name(1, ea.getKey());
world.addObject(name);
return true;
}
// Press a letter key with shift to remove an object.
else if (ea.getKey() >= 'A' && ea.getKey() <= 'Z')
{
std::string name(1, ea.getKey() - ('Z' - 'z'));
world.removeObject(name);
return true;
}

return false;
}
};

int main()
{
osg::ref_ptr currentViewer;

int returnCode = 0;

while (useNewViewer)
{
currentViewer = new osgViewer::Viewer;
currentViewer->setSceneData(world.getScene());
currentViewer->addEventHandler(new EventHandler);

useNewViewer = false;

returnCode = currentViewer->run();
}

return returnCode;
}




Imagine this is part of a world editor for a game or CAD software or one of any 
number of types of software packages where you edit something and might want a 
3D view of it, but wouldn't necessarily always want that 3D view taking up 
space in the window, so you'd possibly close it and then reopen it 

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

[Robert Osfield]

Hi Chris,

On Fri, 12 Apr 2019 at 21:07, Chris Djali  wrote:
> It's been a couple of weeks since the last reply to this. I'm guessing this 
> has fallen off the radar, but I still need to fix the issue, so would 
> appreciate if another look could be taken at this.

There is really enough to go on to be able to diagnose what is going
on, there is a limit to how much we can advise on usage combinations
that we haven't seen locally.

Could you create a small OSG example that illustrates the problem
across the different versions of the OSG.

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

[Chris Djali]

Hi,

It's been a couple of weeks since the last reply to this. I'm guessing this has 
fallen off the radar, but I still need to fix the issue, so would appreciate if 
another look could be taken at this.

Thank you!

Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75828#75828





___
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

[Chris Djali]

All out of the 3.6 branch, 3.4.1 and OpenMW's 3.4.1 fork (which doesn't make 
any changes to osgText, and we're trying to abandon, but it's much faster than 
the official 3.4.1 release). If everything's working as we think it does, 
OpenMW should work with any OSG release after 3.4.

The issue of the text program not being released when the context is torn down 
happens with all the versions listed above. Also, an answer to the question in 
the general case would probably be helpful for all of the versions.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75753#75753





___
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

[Robert Osfield]

Hi Chris,

Which version of the OSG are you working with?

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

[Julien Valentin]

I don't understand:
I can't find any static osg::ref_ptr in osgText/Text...
please give a simple code illustrating your problem


AnyOldName3 wrote:
> The problem is specifically because it's static. Unless I'm manually keeping 
> track of when the last text object is removed from the scene, I can't release 
> the program without it potentially still being in use. If I never release it, 
> references to it can persist beyond the lifetime of the context it was 
> created for.
> 
> 
> Cheers,
> Chris



Twirling twirling twirling toward freedom

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75748#75748





___
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

[Chris Djali]

The problem is specifically because it's static. Unless I'm manually keeping 
track of when the last text object is removed from the scene, I can't release 
the program without it potentially still being in use. If I never release it, 
references to it can persist beyond the lifetime of the context it was created 
for.


Cheers,
Chris

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75747#75747





___
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

[Julien Valentin]

Hi Chris,
I haven't dive into the problem, but would making the osgText::Text::program 
static (and share it with all instances) could be a proper way to handle this 
issue?
Cheers


AnyOldName3 wrote:
> Hi,
> 
> I know that when an OpenGL context is destroyed, the associated viewer can 
> only call releaseGLObjects(osg::State *) for nodes still attached to the 
> scene graph, so if you're removing things before that, you're manually 
> supposed to call releaseGLObjects on the subgraph.
> 
> However, as I see it, there's a potential problem here. If the subgraph 
> contains nodes that share GL objects with things still attached to the main 
> scenegraph, you'll end up releasing those, too. This can mostly be worked 
> around by not sharing GL objects between nodes with different lifetimes, but 
> sometimes that's not possible.
> 
> For example, osgText::Text seems to have a global osg::Program used for all 
> instances (or, at least, all instances with the same settings). If I always 
> call releaseGLObjects when removing subgraphs containing an osgText::Text, 
> it's going to kill the per-context programs and they'll need rebuilding for 
> any other text nodes, which isn't desirable. If I never call 
> releaseGLObjects, then that's even worse (for obvious reasons). It seems like 
> the only good ways of handling this would be to either keep track of when the 
> last text node was removed so the objects could be released when their last 
> user was removed, or move 'removed' objects to another part of the scene 
> graph (e.g. as a disabled osg::Switch child) so they're actually kept around 
> without being drawn, but still get their GL objects released when the context 
> is destroyed. There's also the hacky option of attaching another text node 
> somewhere else in the scenegraph so it always gets released, which works in 
> the specific 
 case of osgText::Text, but won't work in the general case, and doesn't seem 
desirable.
> 
> Is there a better way of handling this than I've suggested here? If there's 
> something intended for this built into OSG that I just don't know about, that 
> would be great, but I'm not going to shy away from writing something custom 
> if that's what's necessary.
> 
> Cheers,
> Chris



Twirling twirling twirling toward freedom

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75740#75740





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org