wxPython 2.6.3.3 different GetDisplayID behaviour?

wxPython Users
1

Dear Robin and list,

It's been reported here that wxPython 2.6.3.3 segfaults with the VTK
wxVTKRenderWindowInteractor.

I've narrowed it down to its use of wxGetXDisplay(). You added this
call in wxPython 2.6.0.1 at my request, in order to fix a nasty NVidia
bug on Linux. I integrated it in VTK. It worked fine up until at
least wxPython 2.6.2.1, but now calling this and converting it for use
in a VTK vtkRenderWindow.SetDisplayId() call segfaults.

#0 0xb6f430a6 in XChangeWindowAttributes () from /usr/lib/libX11.so.6
#1 0xb4b41763 in vtkXOpenGLRenderWindow::WindowInitialize (this=0x8595478)
    at /data/tmp/wd/build/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:370
#2 0xb4b3ed5e in vtkXOpenGLRenderWindow::Initialize (this=0xe0004a)
    at /data/tmp/wd/build/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:486

Did anything change in the behaviour of wxGetXDisplay() between
wxPython 2.6.2.1 and wxPython 2.6.3.3 ? Note, wxGetXDisplay() doesn't
segfault, but it seems that the value it returns is not correct
anymore, OR the things VTK tries to do (it renders to a given display
and window Id) are not allowed anymore by the way that wx sets up the
window.

I would appreciate _any_ info that I could use to fix/workaround this problem.

Thanks,
Charl

2

Charl P. Botha wrote:

Dear Robin and list,

It's been reported here that wxPython 2.6.3.3 segfaults with the VTK
wxVTKRenderWindowInteractor.

I've narrowed it down to its use of wxGetXDisplay(). You added this
call in wxPython 2.6.0.1 at my request, in order to fix a nasty NVidia
bug on Linux. I integrated it in VTK. It worked fine up until at
least wxPython 2.6.2.1, but now calling this and converting it for use
in a VTK vtkRenderWindow.SetDisplayId() call segfaults.

#0 0xb6f430a6 in XChangeWindowAttributes () from /usr/lib/libX11.so.6
#1 0xb4b41763 in vtkXOpenGLRenderWindow::WindowInitialize (this=0x8595478)
   at /data/tmp/wd/build/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:370
#2 0xb4b3ed5e in vtkXOpenGLRenderWindow::Initialize (this=0xe0004a)
   at /data/tmp/wd/build/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:486

Did anything change in the behaviour of wxGetXDisplay() between
wxPython 2.6.2.1 and wxPython 2.6.3.3 ?

No, it just returns the value of GDK_DISPLAY() in each version. I also verified that the wxPython code wrapping wx.Window.GetHandle() hasn't changed.

Note, wxGetXDisplay() doesn't
segfault, but it seems that the value it returns is not correct
anymore, OR the things VTK tries to do (it renders to a given display
and window Id) are not allowed anymore by the way that wx sets up the
window.

I would appreciate _any_ info that I could use to fix/workaround this problem.

Sorry, I can't think of anything.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

3

Charl P. Botha wrote:
> Did anything change in the behaviour of wxGetXDisplay() between
> wxPython 2.6.2.1 and wxPython 2.6.3.3 ?

No, it just returns the value of GDK_DISPLAY() in each version. I also
verified that the wxPython code wrapping wx.Window.GetHandle() hasn't
changed.

Robin, have a look at this:

wxPython 2.6.2.1, Python 2.4.3

import wx
d = wx.GetXDisplay()
print d

_10574308_p_void

d.__hex__()

'8435710'

wxPython 2.6.3.3, Python 2.5

import wx
d = wx.GetXDisplay()
print d

_783d3f08_p_void

d.__hex__()

'0x83f3d78'

It seems the behaviour of the __hex__ method of the returned swig
object has changed. Is this due to the different Python versions
(that would be strange) or due to some other change in the wxPython
wrappings?

By the way, this is the reason why VTK is currently broken on wxPython
2.6.3.3 on Linux. I'll make a fix for this and commit to VTK CVS.

See you,
Charl

···

On 10/6/06, Robin Dunn <robin@alldunn.com> wrote:

4

Seems Prabhu already fixed this in VTK CVS!!

Argh, I should have checked before going into debug mode. :slight_smile:

···

On 10/7/06, Charl P. Botha <cpbotha@cpbotha.net> wrote:

By the way, this is the reason why VTK is currently broken on wxPython
2.6.3.3 on Linux. I'll make a fix for this and commit to VTK CVS.

5

Charl P. Botha wrote:

···

On 10/6/06, Robin Dunn <robin@alldunn.com> wrote:

Charl P. Botha wrote:
> Did anything change in the behaviour of wxGetXDisplay() between
> wxPython 2.6.2.1 and wxPython 2.6.3.3 ?

No, it just returns the value of GDK_DISPLAY() in each version. I also
verified that the wxPython code wrapping wx.Window.GetHandle() hasn't
changed.

Robin, have a look at this:

wxPython 2.6.2.1, Python 2.4.3

import wx
d = wx.GetXDisplay()
print d

_10574308_p_void

d.__hex__()

'8435710'

wxPython 2.6.3.3, Python 2.5

import wx
d = wx.GetXDisplay()
print d

_783d3f08_p_void

d.__hex__()

'0x83f3d78'

It seems the behaviour of the __hex__ method of the returned swig
object has changed. Is this due to the different Python versions
(that would be strange) or due to some other change in the wxPython
wrappings?

A new version of SWIG.

BTW, if you're just wanting to get the numeric value of the pointer you can use long(d). That will give you an actual number instead of a string representing a number.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!