Re: [wxVTK] wxAuiNotebook with wxVTK

[Sander N. <nie...@st...>]

Hi Mathieu,

The problem is a matter of ownership. There are situations where you  
have to give ownership over who is responsible for deleting the wxVTK  
object to some other component (depending on the design of the  
framework you are using). In the situation I had it was because I use  
a Python wrapping for wxVTK. Because of the garbage collection that  
Python uses I can't call Delete() myself but have to rely on the fact  
that Python (through a SWIG wrapping) will call delete on the wxVTK  
object.

My guess is that for the wxAuiNotebook the same reasoning holds. You  
can't call Delete() yourself, because the wxAuiNotebook has ownership  
of the destruction, so there is no single point where you can 'assist'  
in destroying the wxVTK object. In other words, you _should not_ call  
'delete' or 'Delete()' yourself!

So what does it mean if another component calls 'delete' on the wxVTK  
object?
1) It breaks the operation of all objects that still have a reference  
to the wxVTK object
2) It breaks the final decrement that a call of wxVTK::Delete() would  
do if there would be no further references (which raises a "Trying to  
delete object with non-zero reference count." error if the  
vtkObjectBase destructor gets called for the wxVTK object)

So how do we remedy this?
For the first problem we need to make sure that we have no more  
references to our object. For my purposes calling the  
SetRenderWindow(NULL) and SetInteractorStyle(NULL) from the wxVTK  
object destructor was sufficient. But depending on how you use the  
wxVTK object in your code you may have to remove additional references  
as well.
For the second problem I use the 'if (GetReferenceCount() == 1)  
SetReferenceCount(0);' trick in the destructor.


P.S. I saw that several of the items of the patch that I send in  
August last year are not in HEAD (yet). If you want to discuss them  
please drop me an email. Most importantly for me would be to drop the  
'#if (!wxCHECK_VERSION(2, 8, 0))' part. It may also be good to mention  
that wxWidgets 2.8 no longer supports GTK 1.2 (there are a lot of  
things broken). You will have to use GTK 2.x if you want to use  
wxWidgets 2.8.0. For our application we changed at some point from  
wxWidgets 2.6/GTK 1.2 to wxWidgets 2.8/GTK 2.x (we never got wxWidgets  
2.6 properly working with GTK 2.x). Your mention in  
wxVTKRenderWindowInteractor.h of the flickering was I think exactly  
that issue. But this would then mean that:
- wxWidgets 2.6 + GTK 1.2 -> use wxGLCanvas
- wxWidgets 2.6 + GTK 2.0 -> don't use wxGLCanvas
- wxWidgets 2.8 + GTK 1.2 -> will never work
- wxWidgets 2.8 + GTK 2.0 -> don't use wxGLCanvas

Best regards,
Sander

On 8 apr 2008, at 16:27, Mathieu Malaterre wrote:
> Hi there !
>
>  Long time no activity on wxVTK, glad to see it is still active :)
>
>  Kerry, I made some minor tweaks to the wxVTK class so that the
> annoying debug leaks message does not appear anymore. You can now
> build VTK with DEBUG_LEAKS=ON safely.
>
> On Mon, Apr 7, 2008 at 11:33 PM, Sander Niemeijer  
> <nie...@st...> wrote:
>> wxWidgets and VTK use different ways to delete objects. In this case
>> you want to delete it yourself the VTK way which is using '...-
>>> Delete()' and on the other hand a wx object is doing it the
>> wxWidgets way and thinks it can call 'delete ...'. This generates a
>> conflict. The delete will not decrese the VTK refcount and will  
>> result
>> in your VTK error, but you can't really prevent the call to delete
>> either (so doing your own Delete() will also give you trouble).
>>
>> I had this problem as well and got it solved differently: I was
>> already using a derived class of wxVTKRenderWindowInteractor and for
>> that class I added the following part to the destructor (at the end):
>>
>> ----
>>     SetRenderWindow(NULL);
>>     SetInteractorStyle(NULL);
>
>
> That's always safe AFAIK. I can add those two lines to the  
> destructor of wxVTK.
>
>>     // Normally one has to remove a wxVTKRenderWindowInteractor
>> object using 'window->Delete()',
>>     // but we also would like 'delete window' to work (which is
>> needed for e.g. Python wrapping)
>
>
> Yeah, that's where you got me lost. ->Delete() from VTK world always
> 'delete this', so whatever wxWindows wants should be included in the
> destructor (~wxVTK), but ->Delete is just a convention to call
> ~wxVTK() before doing some other VTK cleanups.
>
>>     // This should be safe as long the reference count is 1 (i.e. no
>> other objects have a reference to this object)
>>     // The problem is that we can't use Delete() or Unregister(NULL)
>> here, because that would recursively invoke the
>>     // destructor. Therefore, we just explicitly decrease the
>> reference count by 1 if it was 1 (this way you will still
>>     // get a warning from VTK if the reference count afterwards was
>> not 0).
>>     if (GetReferenceCount() == 1)
>>     {
>>         SetReferenceCount(0);
>>     }
>> ---
>>
>> This is the safest solution to this issue that I know of.
>> Note that it also doesn't break a delete using the VTK-style Delete()
>> mechanism (since it won't do anything special if the reference count
>> is already 0, and the VTK Delete function will never call the
>> destructor if the refcount was still higher than that).
>>
>> For your situation, you could probably adapt the
>> wxVTKRenderWindowInteractor.cpp itself (instead of creating a
>> subclass) and add the given routines to the (currently empty)
>> wxVTKRenderWindowInteractor destructor.
>>
>> If this does indeed work, I think it might even be worth considering
>> to add this reference count trick to the wxVTKRenderWindowInteractor
>> destructor of the official wxVTKRenderWindowInteractor package.  
>> Mathieu?
>
>
> I fixed the debug leaks thingy so that vtkDebugLeaks properly report
> whether or not every VTK classes has been deleted. AFAIK everything
> should be  fine now (ie all vtkObject have a ref count == 0 at
> destruction time).
> I know that on Win32 there are some issues, which I thought were fixed
> in VTK 5.0, but this can be fixed as you mentionned by explicitely
> setting the Renderwindow to NULL before destruction.
>
> I'll add those two lines. And since I have some time on my hands, I'll
> review the couple of patch that were send to the mailing list, but
> from the top of my head they were already in CVS HEAD, simply not in
> wxVTK 1.2
>
> Thanks everybody for continued support and suggestions,
> -- 
> Mathieu
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Register now and save $200. Hurry, offer ends at 11:59 p.m.,
> Monday, April 7! Use priority code J8TLD2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Wxvtk-users mailing list
> Wxv...@li...
> https://lists.sourceforge.net/lists/listinfo/wxvtk-users