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 cal
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
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'
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
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 t
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.opensc
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
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 num
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
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
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
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 us
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 th
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::G
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
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
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 t
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 se
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
_decor
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 nec
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 expec
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
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 n
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://
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 wan
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 wan
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.
Th
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 osgT
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
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-openscen
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'
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 rel
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
sharin
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::releaseG
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 cont
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 came
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
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
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,
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
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 goi
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
Hi,
> So... would change the destructor to:
>
>
> Camera::~Camera()
> {
> setCameraThread(0);
>
> if (_graphicsContext.valid())
>
> {
>releaseGLObjects(_graphicsContext->getState());
>
>
> _graphicsContext->removeCamera(this);
> }
> else
> {
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
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 m
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.
__
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 se
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.or
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
l
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
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::Vie
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 ca
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
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:
#i
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
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.openscenegr
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 top
57 matches
Mail list logo
