Re: [osg-users] Removing objects with shared GL state from scene graph
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
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
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
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(&argc, 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(&viewer)); } // run the viewer's main frame loop return viewer.run(); } This started life as the
Re: [osg-users] Removing objects with shared GL state from scene graph
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Hi Chris, I observed, that also CameraManipulators keep a reference to the camera. This prohibits then the release of the gl objects. Martin Chris Djali schrieb am Fr., 26. Juli 2019, 08:38: > 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 > ___ 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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Re: [osg-users] Removing objects with shared GL state from scene graph
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
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
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
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 l
Re: [osg-users] Removing objects with shared GL state from scene graph
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
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
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
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
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
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
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
[osg-users] Removing objects with shared GL state from scene graph
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 ca se 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 -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75726#75726 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org