[vtkusers] GLXBadDrawable on application exit

[Félix C. Morency]

Clinton,

Correct me if I'm wrong but the C++ QVTKWidget wrapped for Python is
only available for PyQt, not PySide (which use Shiboken to create
bindings, not SIP).

I'm trying to implement your idea with the hidden child widget, but I
am facing (I think) a PySide issue.

I might look at creating the PySide bindings for QVTKWidget if I keep
facing issues.

Regards,
-F

On Tue, Jul 3, 2012 at 6:26 PM, Clinton Stimpson <clinton at elemtech.com> wrote:
>
> Here's another idea... could QVTKRenderWindowInteractor create a hidden child
> widget, connect to its destroyed() signal and call vtkRenderWindow::Finalize()
> then?  Would that work for all embedded vs. non-embedded cases?
>
> Using its own destroyed() signal is too late, but child widgets are destroyed
> before any cleanup of itself starts.
>
> Alternatively, you can use the C++ QVTKWidget wrapped for Python.  Its
> destructor does this kind of cleanup.
>
> Clint
>
> On Tuesday, July 03, 2012 04:38:53 PM Félix C. Morency wrote:
>> Adding the closeEvent handler works for non-embedded
>> QVTKRenderWindowInteractor. I think we should push this. Do you want
>> me to prepare a patch?
>>
>> I found three ways of solving the issue of embedded interactors:
>>
>> 1) Subclass QMdiSubWindow, render on a QFrame and call close() on the
>> VTK interactor from the QMdiSubWindow closeEvent [1]
>> 2) Subclass the rendering surface (QFrame) and call close() on the VTK
>> interactor from the QFrame closeEvent [2]
>> 3) Install a custom event filter (QObject.installEventFilter) on the
>> rendering surface (QFrame) and call close() from the eventFilter
>> method [3]
>>
>> I don't like 1) because the content of the created subwindow is
>> limited by the subclass. I don't like 2) because a subclassing would
>> be needed for each desired rendering surface... although I don't know
>> if anything else than a QFrame is usable. I like 3) because the event
>> filter can be installed on any QObject and shaped as desired.
>>
>> [1]: https://gist.github.com/3042843
>> [2]: https://gist.github.com/3042849
>> [3]: https://gist.github.com/3042862
>>
>> Feel free to comment if I am missing some details. Do you think we
>> should create a proper filter and add it to VTK? Or simple heavily
>> document this case somewhere?
>>
>> -F
>>
>> On Mon, Jul 2, 2012 at 4:07 PM, Clinton Stimpson <clinton at elemtech.com>
> wrote:
>> > I don't see a way to have Qt tell you when its going to destroy the
>> > window. Perhaps you can add a
>> > def closeEvent(self, ev):
>> >   self._RenderWindow.Finalize()
>> >
>> > That might be harmless even if one wants to show the window again.
>> >
>> > Clint
>> >
>> > On Wednesday, June 27, 2012 01:45:33 PM Félix C. Morency wrote:
>> >> Clinton,
>> >>
>> >> Thank you for your answer. Destructors in Python are a bit tricky and
>> >> I'm not too familiar with it. If I understand correctly, the __del__()
>> >> method will be called if the reference count to the current object is
>> >> zero. However, it seems that the reference count of the
>> >> QVTKRenderWindowInteractor will never be zero because of self
>> >> reference given by the lines:
>> >>
>> >>     self._Iren.AddObserver('CreateTimerEvent', self.CreateTimer)
>> >>     self._Iren.AddObserver('DestroyTimerEvent', self.DestroyTimer)
>> >>     self._Iren.GetRenderWindow().AddObserver('CursorChangedEvent',
>> >> self.CursorChangedEvent)
>> >>
>> >> If I comment those lines anyway, the following destructor is called:
>> >>
>> >>    def __del__(self):
>> >>        self._RenderWindow.Finalize()
>> >>
>> >> However, I still have the GLXBadDrawable errors when creating multiple
>> >> embedded VTK window.
>> >>
>> >> Also, if I had
>> >>
>> >>     vtk_interactor1.Initialize()
>> >>     vtk_interactor2.Initialize()
>> >>
>> >> after the lines
>> >>
>> >>     vtk_interactor1 = QVTKRenderWindowInteractor(parent=qframe1)
>> >>     vtk_interactor2 = QVTKRenderWindowInteractor(parent=qframe2)
>> >>
>> >> of the code snippet of my previous message, the application segfault.
>> >> However, if I start that same application with the '-sync' parameter
>> >> you mentioned in the other email thread, it works. You can find
>> >> another example in [1] that works with and without the '-sync'
>> >> parameter. This time, the two Initialize() calls don't crash the
>> >> application. The main difference is that the windows are not embedded
>> >> in a MdiArea. However, I still have GLXBadDrawable, even with the
>> >> added destructor in QVTKRenderWindow.
>> >>
>> >> [1]: https://gist.github.com/3005627
>> >>
>> >> Regards,
>> >> -F
>> >>
>> >> On Fri, Jun 22, 2012 at 6:42 PM, Clinton Stimpson
>> >> <clinton at elemtech.com>
>> >
>> > wrote:
>> >> > QVTKRenderWindowInteractor needs a destructor that calls
>> >> > Finalize() on
>> >> > the vtkRenderWindow.
>> >> > Otherwise, vtkXOpenGLRenderWindow::Finalize() will be called after
>> >> > the
>> >> > QWidget is gone, leading to X errors with an invalid Window.
>> >> >
>> >> > Clint
>> >> >
>> >> > On Thursday, June 21, 2012 02:11:36 PM Félix C. Morency wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I posted this issue in another thread on the developers mailing
>> >> >> list
>> >> >> but felt I should post it here. I encounter GLXBadDrawable
>> >> >> errors when I exit an application rendering multiple
>> >> >> QVTKRenderWindowInteractor in a QMdiArea. The GLXBadDrawable
>> >> >> looks like
>> >> >>
>> >> >> X Error of failed request:  GLXBadDrawable
>> >> >>   Major opcode of failed request:  135 (GLX)
>> >> >>   Minor opcode of failed request:  5 (X_GLXMakeCurrent)
>> >> >>   Serial number of failed request:  95
>> >> >>   Current serial number in output stream:  95
>> >> >>
>> >> >> You can find in [1] a code snippet that reproduces the issue. It
>> >> >> happens on Linux as well as on Windows. It has been tested with
>> >> >> PySide v1.1.1, PyQt4 v4.9.1 and VTK 5.10.0.
>> >> >>
>> >> >> Does anyone have a clue why this is happening?
>> >> >>
>> >> >> [1]: https://gist.github.com/2967336
>> >> >>
>> >> >> Regards,
>> >> >> --
>> >> >> Félix C. Morency, M.Sc.
>> >> >> Plateforme d’analyse et de visualisation d’images
>> >> >> Centre Hospitalier Universitaire de Sherbrooke
>> >> >> Centre de recherche clinique Étienne-Le Bel
>> >> >> Local Z5-3031 | 819.346.1110 ext 16634
>> >> >> _______________________________________________
>> >> >> Powered by www.kitware.com
>> >> >>
>> >> >> Visit other Kitware open-source projects at
>> >> >> http://www.kitware.com/opensource/opensource.html
>> >> >>
>> >> >> Please keep messages on-topic and check the VTK FAQ at:
>> >> >> http://www.vtk.org/Wiki/VTK_FAQ
>> >> >>
>> >> >> Follow this link to subscribe/unsubscribe:
>> >> >> http://www.vtk.org/mailman/listinfo/vtkusers
>> >> >
>> >> > --
>> >> > Clinton Stimpson
>> >> > Elemental Technologies, Inc
>> >> > Computational Simulation Software, LLC
>> >> > www.csimsoft.com
>> >
>> > --
>> > Clinton Stimpson
>> > Elemental Technologies, Inc
>> > Computational Simulation Software, LLC
>> > www.csimsoft.com
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Please keep messages on-topic and check the VTK FAQ at:
>> > http://www.vtk.org/Wiki/VTK_FAQ
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://www.vtk.org/mailman/listinfo/vtkusers
> --
> Clinton Stimpson
> Elemental Technologies, Inc
> Computational Simulation Software, LLC
> www.csimsoft.com



-- 
--
Félix C. Morency, M.Sc.
Plateforme d’analyse et de visualisation d’images
Centre Hospitalier Universitaire de Sherbrooke
Centre de recherche clinique Étienne-Le Bel
Local Z5-3031 | 819.346.1110 ext 16634