[osg-users] Crash on exit (graphics thread removing camera)

[Robert Osfield]

Hi Jannik,

On 16 August 2016 at 15:28, Jannik Heller <scrawl at baseoftrash.de> wrote:
> Yes you can break it that way but I'm actually talking about a different breakage - the fact that resources get cleaned up that should *not* be cleaned up because they're still in use.
>
> Consider:
>
> - Camera1
> -- Node1
> --- Geometry1
>
> - Camera2
> -- Node2
> --- Geometry1
>
> Now if we remove Camera1, Geometry1 gets releaseGLObjects() even though it's still being used by Camera2. This will result in frame drops because the objects have to be recompiled on the next frame.
>
> This is not a "corner case", doing resource sharing between cameras is something that everyone will do to improve the performance.

Sharing subgraphs is normal, the thing that is not normal is removing
stuff from the scene graph whilst it's being actively rendered.
Adding and removing objects from the scene graph whilst it's being
actively rendered is a special case that needs special handling to
make sure it happens safely.

> My argument is that the releaseGLObjects() in GraphicsContext::removeCamera is so broken that we should simply remove it.

Not sure why you think it's broken.

> That cleanup shouldn't be necessary anyway because the GL objects are released when objects are destroyed. So if the object was only in use by that Camera (i.e. no other reference to it), the object gets destroyed and releaseGLObjects() after the Camera is destroyed. If there are still references to the object, then the user is obviously still using it so we should not releaseGLObjects() on it.

The problem is you are destroying some objects that have GL objects
that need clean up so releaseGLObjects() is required, but you're
breaking this by sharing objects.  For the OSG to *know* what you are
doing with your application and what parts you are intended to release
and parts you want to reuse is not trivial to work out automatically.
The only safe thing to do is release the objects and let them be
reallocated as required.

The alternative for you is simply not going deleting nodes.

You need to think about whether you need to delete Camera's
dynamically during the applications life, you haven't explained why
you are doing this and why not keeping the Camera around is not
appropriate so I can't comment on the validity of what you are doing.

If Performance is critical for you then you shouldn't be avoiding
deleting nodes during the lifetime of the rendering as deleting
objects in C++ and especially in OpenGL is very expensive and can
easily break frame.  If performance isn't an issue then using
multi-threading won't be required.  I don't know what the performance
requirements are you your applications.

Also something that seems a bit odd - why an in scene graph Camera has
a GraphicsContext assigned to it.  Normally in scene graph Camera
don't have an GraphicsContext, instead inherit the GraphicsContext
from the viewer's Camera.  If  Camera needs it's own
GraphicsContext/Window then would typically best done by having a
Camera at the Viewer level rather than in the scene graph.   Again I
don't know why you've gone for the approach you have, all I can say it
might not be appropriate.

Robert.