[vtkusers] GLXBadDrawable on application exit
Félix C. Morency
felix.morency at gmail.com
Mon Jul 9 13:22:58 EDT 2012
Clinton,
I pushed a patch on Gerrit [1] providing the fix and a test case for
QVTKRenderWindowInteractor.
[1]: http://review.source.kitware.com/#/t/895/
-F
On Fri, Jul 6, 2012 at 10:54 AM, <clinton at elemtech.com> wrote:
> 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
>>
--
--
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