[vtk-developers] Crash with OpenGL2 Renderer only in vtkOpenGLBufferObject destructor.

Thu Sep 1 12:33:08 EDT 2016

Got it, I'll take a look. - Ken

On Wed, Aug 31, 2016 at 3:57 PM, Seun Odutola <seun at rogue-research.com>
wrote:

> Thanks for the detailed response.
>
> We have created a simple test app that mimics our main app in order to
> simplify the task of debugging and still the crash reproduces itself.  On
> reviewing our test app alongside your response I can say that we are not
> violating any of the warnings / points stated. No actors are being shared
> between render windows, nor mappers. Each window has its actor and mappers
> separated (thus they act as standalone).
>
> Recall that our crash occurs when setting the mapper of an actor (changing
> its previous mapper).
>
> Our application is Mac-based and there are two main ways to draw on OS X:
> via NSView or via CALayer.  It seems the crash only occurs when we draw via
> CAOpenGLLayer and not when using NSView.  This is mysterious to us.
>
> Our test app is based on the VTK/Examples/GUI/Cocoa sample.  Do you think
> you could take a look?  We annotated the interesting bits with "Ken"
> comments.  It's here:
>
> https://www.rogue-research.com/Foo.zip
>
> To reproduce the crash:
>  - launch the app
>  - click “create actor" next to one vtk renderwindow
>  - click "X" next to the other vtk renderwindow
>  - click “swap mapper" next to the first vtk render window
>
>
> p.s: I would also like to know from your previous response “You would need
> to call release graphics resources every time you switch which window is
> active to make sure the buffers etc all rebuilt” - does this also mean for
> instance if we have 2 render windows and we close our which in turns makes
> the last one active do we need to call release graphics resources on the
> one just terminated? Just wondering.
>
>
>
> On Aug 25, 2016, at 7:12 PM, Ken Martin <ken.martin at kitware.com> wrote:
>
> - actors are tied to a particular render window
>>   - thus they can't be added to two render windows, or moved between two,
>> etc.
>>
>
> Essentially yes, mainly because an actor has a mapper and mappers should
> not be shared between windows.
>
>
>> - mappers are likewise tied to a particular render window
>>
>
> Yes. Mappers create buffer objects that are tied to a window's OpenGL
> context. Right now we do not support sharing buffers between contexts (it
> could be added) so having the same mapper in two windows would either cause
> the buffers to be rebuilt and sent down every frame or an OpenGL error. You
> could share an actor/mapper between two windows if you knew only one would
> active at a time. You would need to call release graphics resources every
> time you switch which window is active to make sure the buffers etc all
> rebuilt. But the general answer is they are not designed to be shared.
>
>
>> - it is permitted to change an actor's mapper
>>
>
> Yes, to a new mapper it should be fine. If reusing an existing mapper from
> another window you must call ReleaseGraphicsResources before using it in a
> different window.
>
>
>> - a single mapper can be shared by multiple actors
>>
>>
> Uh. Maybe :-) So a single mapper, shared by multiple actors in the same
> window (they can be in different renderers) should not crash. My concern is
> that the rendering process keeps track of a lot of modified times to know
> when to rebuild or change "things". With multiple actors sharing the same
> mapper you may either end up with changes not being reflected or the mapper
> rebuilding every time. For example if you had two actors, two properties,
> one mapper. One property is set to wireframe, the other to surface. It
> might well work, but the mapper would be rebuilding the IBOs every single
> frame because it uses different IBOs for wireframe versus surface.
>
> Is that all correct?
>>
>>
> Let me try to add some meta comments here that may help. Actors are light
> weight, feel free to make two if you need two. Making thousands is a
> different story but generally there is no performance advantage to sharing
> them. Same with lights, and properties.
>
> Mappers hold and build a lot of buffers and those buffers are heavily
> dependent on the properties/etc. Mappers can consume a lot of memory if
> their data is large so I can see the desire to share them if you want the
> same geometry in multiple windows or viewports. The mapper is not really
> coded to be shared. If you have a use case where sharing a mapper would be
> good then the right solution would be to add some sort of buffer sharing
> cache in VTK. I would like to see that at some point as it has value and
> doesn't seem crazy hard.
>
> If you are creating/rendering thousands of separate items, then the right
> solution depends on the specifics our your situation. For example,
> glyph3dmapper is great at drawing thousands of the same geometry in
> different places, with different colors, and even different
> orientations/scales. It can do it very quickly and with a low memory
> footprint. Creating actors for all of those would be far more costly.
> Thousands of spheres/cylinders, the OpenGLSphereMapper or
> OpenGLCylinderMapper etc. Lots of different geometry with different
> visibility/color vtkCompositePolyDataMapper2 is the best choice.
>
> Hope that Helps
> Ken
>
>
>
>
>> Thanks,
>>
>> Sean
>>
>>
>> On Thu, 11 Aug 2016 14:31:31 -0400, Seun Odutola said:
>>
>> >Hi Ken,
>> >
>> >I have a scenario where I have an actor and a mapper connected to it (so
>> >in the application window it renders i.e: a sphere). The user has the
>> >ability to change the shape (to cube for example) via the UI, so
>> >internally this is what I’m doing: I have an actor that I keep around,
>> >when the user changes the shape, I just create a new mapper and set the
>> >actor’s mapper directly to the new one (not calling the
>> >ReleaseGraphicsResources).
>> >
>> >First, is this reasonable? Or every time I need to create a new mapper
>> >is it best to also create a new actor to connect it to? or does it
>> >suffice to just swap the actor’s mapper by calling SetMapper()? In the
>> >latter case, then one needs to call ReleaseGraphicsResources on the
>> >previous mapper prior to setting up a new one, right?
>> >
>> >Relatedly, I would like to know for the sake of clarity if mappers can
>> >be shared between actors; that is, is the relationship of an actor and
>> >its mapper a 1 to 1 relationship?
>> >
>> >Regards,
>> >   Seun
>> >
>> >> On Aug 11, 2016, at 11:52 AM, Seun Odutola <seun at rogue-research.com>
>> wrote:
>> >>
>> >> Thanks for the expeditious and detailed response Ken, I truly
>> >appreciate it. Perfect, this is exactly what I thought but needed the
>> >opinion of someone more experienced. I had a closer look at vtkActor and
>> >noticed how it checks the validity of it’s Mapper prior to releasing it
>> >(in its release graphics resource function) proof that it indeed needs
>> >to be released via calling ReleaseGraphicsResources sometime down the
>> >line. Thanks
>> >>
>> >> Regards,
>> >>    Seun.
>> >>
>> >>> On Aug 11, 2016, at 11:44 AM, Ken Martin <ken.martin at kitware.com
>> ><mailto:ken.martin at kitware.com>> wrote:
>> >>>
>> >>> Yes you definitely want to call ReleaseGraphicsResources when you are
>> >done using a graphics object, but are not done using its window.
>> >Normally VTK handles this for you so you do not have to worry about it.
>> >>>
>> >>> Many classes in VTK create and hold onto OpenGL resources. At some
>> >point those resources need to be freed. Normally before an OpenGL
>> >context/window is destroyed it will call ReleaseGraphicsResources on
>> >everything connected to it so that they are all freed before it releases
>> >the context. But if you have detached a mapper from the RenderWindow/
>> >Renderer/Actor (but not yet deleted it) then that does not happen. Then
>> >at some other point that mapper tries to free its resources but the
>> >context that owned them is already gone causing an error.
>> >>>
>> >>> Thanks
>> >>> Ken
>> >>>
>> >>>
>> >>>
>> >>> On Thu, Aug 11, 2016 at 11:33 AM, Seun Odutola <seun at rogue-
>> >research.com <mailto:seun at rogue-research.com>> wrote:
>> >>> Hi Ken,
>> >>>
>> >>>     Thanks for the suggestion. I do have a little question though, is
>> >it a necessary convention to call release graphics resources on the old
>> >mapper prior to setting a new one? I was wondering judging from your
>> >statement (quick fix) if this was just a hack.
>> >>>
>> >>> Regards,
>> >>>     Seun
>> >>>> On Aug 8, 2016, at 1:00 PM, Ken Martin <ken.martin at kitware.com
>> ><mailto:ken.martin at kitware.com>> wrote:
>> >>>>
>> >>>> How do you change the mapper? Do you immediately destroy the old
>> >mapper or leave it around for  later? I suspect the old mapper is
>> >getting destroyed later than it should. One thing you can try as a quick
>> >fix is
>> >>>>
>> >>>> actor->SetMapper(shiny new mapper);
>> >>>> oldMapper->ReleaseGraphicsResources(renWin or NULL if you don;t have
>> >the window handy)
>> >>>> ...
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Thu, Aug 4, 2016 at 3:21 PM, Seun Odutola <seun at rogue-
>> >research.com <mailto:seun at rogue-research.com>> wrote:
>> >>>> Hello everyone,
>> >>>>
>> >>>>       I have a crash that occurs in my application when running vtk
>> >with the GL2 rendered enabled but not with GL1. So here is the
>> >situation, in my program when I change the shape of my poly data mapper,
>> >basically setting the mapper of an actor in my scene to a new poly data
>> >mapper it results in a crash.  The crash is  situated in
>> >vtkOpenGLBufferObject’s destructor, specifically the deletion of the
>> >Internal’s handle. I have tried to verify if the handle is valid prior
>> >to reaching the destructor which it seems to be, my main concern is if
>> >the handle is filled with garbage (a non-zero value) it might
>> >effectively pass the test condition and try to invoke glDeleteBuffer.
>> >Has anyone experienced anything similar to this?
>> >>>>
>> >>>> Regards,
>> >>>>    Seun
>>
>>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
>
>
>

-- 
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160901/94f6cc8d/attachment-0001.html>