[vtkusers] GLXBadDrawable on application exit

clinton at elemtech.com clinton at elemtech.com
Fri Jul 6 10:54:08 EDT 2012 

That's great news.

And yes, you were right about the sip vs. shiboken thing.

Clint

----- Original Message -----
> Clinton,
> 
> Good news. The idea of the hidden QWidget() works for both embedded
> and non-embedded cases. The GLXBadDrawable errors are finally gone. I
> will submit this to gerrit soon.
> 
> Regards,
> -F
> 
> On Thu, Jul 5, 2012 at 3:25 PM, Félix C. Morency
> <felix.morency at gmail.com> wrote:
> > 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
> 
> 
> 
> --
> --
> 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
>

More information about the vtkusers mailing list