Re: [Dri-devel] reproducible VTK + DRI breakage

2003-03-12 Thread Dieter Nützel
Am Dienstag, 11. März 2003 11:06 schrieb Keith Whitwell:
 Charl P. Botha wrote:
  On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote:
 Charl P. Botha wrote:
 In anycase, if you have wxPython and VTK with working Python wrappings
 installed, please run the attached example.  Manipulate the 3D cone in
  both windows and then close the one window.  Manipulating the remaining
  3D cone for a second or two should result in a drmCmdBuffer: -22
  application crash.
 
 You'll be pleased to hear that I've now got access to a HT enabled box
  with which I can reproduce some or all of the problems you guys have
  been seeing with threaded apps.  Hopefully there'll be some fixes soon.
 
  Hmmm, new toys to play with!   Thanks for thinking about us. ;)
 
  Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on
  my box.  I have not been able to reproduce it since with VTK or
  synthetic tests.

 Can you summarize the problems that remain?  I'm seeing all manner of bad
 behaviour with glthreads - lots of GL_INVALID_OPERATION errors, lots of
 'holds heavyweight lock' errors, the occasional lockup.  It's a mess...

Ack.

VTK
TaskParallelismWithPorts:
all (inner) triangles of the isosurface are not (wrong) colored
= R200_NO_TCL fix it

VTK/bin ./TaskParallelism
TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion 
`vb.context == ctx' failed.
Abbruch (core dumped)

!!! Screen corruption in some upper lines !!!

Redraw fix it.

VTK/bin ./TaskParallelism
TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion 
`vb.context == ctx' failed.
Abbruch (core dumped)

Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...done.
Loaded symbols for /usr/X11R6/lib/modules/dri/r200_dri.so
#0  0x41427701 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x41427701 in kill () from /lib/libc.so.6
#1  0x412b589a in pthread_kill () from /lib/libpthread.so.0
#2  0x412b5d92 in raise () from /lib/libpthread.so.0
#3  0x41428a23 in abort () from /lib/libc.so.6
#4  0x414220ea in __assert_fail () from /lib/libc.so.6

#5  0x4188c845 in r200VtxFmtFlushVertices () from 
/usr/X11R6/lib/modules/dri/r200_dri.so

#6  0x401b1950 in vtkOpenGLRenderWindow::SetPixelData ()
   from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so
#7  0x40048d40 in vtkCompositeManager::Composite ()
   from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so
#8  0x40047de9 in vtkCompositeManager::EndRender ()
   from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so
#9  0x40046379 in vtkCompositeManagerEndRender ()
   from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so
#10 0x410f7afd in vtkCallbackCommand::Execute ()
   from /opt/VTK/V4.0/VTK/lib/libvtkCommon.so
#11 0x4113c5ea in vtkSubjectHelper::InvokeEvent ()
   from /opt/VTK/V4.0/VTK/lib/libvtkCommon.so
#12 0x4113c962 in vtkObject::InvokeEvent () from 
/opt/VTK/V4.0/VTK/lib/libvtkCommon.so
#13 0x4017ff11 in vtkRenderWindow::Render () from 
/opt/VTK/V4.0/VTK/lib/libvtkRendering.so
#14 0x401bb3da in vtkXOpenGLRenderWindow::Render ()
   from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so
#15 0x401a74de in vtkXRenderWindowInteractorCallback ()
   from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so
#16 0x40d55f3e in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6
#17 0x40d56832 in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.6
#18 0x40d56bb9 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
#19 0x401a6852 in vtkXRenderWindowInteractor::Start ()
   from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so
#20 0x40047658 in vtkCompositeManager::StartInteractor ()
   from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so
#21 0x08049670 in process ()
#22 0x4006e964 in vtkThreadedController::Start ()
   from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so
#23 0x4006e7c0 in vtkThreadedController::vtkThreadedControllerStart ()
   from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so
#24 0x41139be1 in vtkMultiThreader::SingleMethodExecute ()
   from /opt/VTK/V4.0/VTK/lib/libvtkCommon.so
#25 0x4006eb40 in vtkThreadedController::SingleMethodExecute ()
   from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so
#26 0x08049716 in main ()
#27 0x414177d1 in __libc_start_main () from /lib/libc.so.6

(gdb) info registers
eax0x0  0
ecx0x6  6
edx0x412c127c   1093407356
ebx0x14d2   5330
esp0xbfffe998   0xbfffe998
ebp0xbfffe9b4   0xbfffe9b4
esi0x14d2   5330
edi0x412ba8c0   1093380288
eip0x41427701   0x41427701
eflags 0x202514
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x2b 43
gs 0x2b 43
fctrl  0x37f895
fstat  0x0  0
ftag   0x0  0
fiseg  0x0  0
fioff  0x0  0
foseg  0x1f80   8064
fooff  0x0  0
fop0x0  0
xmm0   0x
xmm1   0x
xmm2   

Re: [Dri-devel] reproducible VTK + DRI breakage

2003-03-12 Thread Dieter Nützel
Am Dienstag, 11. März 2003 18:29 schrieb Michel Dänzer:
 RADEON_NO_VTXFMT=1

NO, not for me.

VTK/bin ./TaskParallelism
Speicherschutzverletzung (core dumped)

DRI CVS taken on 10.03.2003.

-Dieter



---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] reproducible VTK + DRI breakage

2003-03-12 Thread Dieter Nützel
Am Mittwoch, 12. März 2003 16:42 schrieb Dieter Nützel:
 Am Dienstag, 11. März 2003 11:06 schrieb Keith Whitwell:
  Charl P. Botha wrote:
   On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote:
  Charl P. Botha wrote:
  In anycase, if you have wxPython and VTK with working Python wrappings
  installed, please run the attached example.  Manipulate the 3D cone in
   both windows and then close the one window.  Manipulating the
   remaining 3D cone for a second or two should result in a
   drmCmdBuffer: -22 application crash.
  
  You'll be pleased to hear that I've now got access to a HT enabled box
   with which I can reproduce some or all of the problems you guys have
   been seeing with threaded apps.  Hopefully there'll be some fixes
   soon.
  
   Hmmm, new toys to play with!   Thanks for thinking about us. ;)
  
   Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on
   my box.  I have not been able to reproduce it since with VTK or
   synthetic tests.
 
  Can you summarize the problems that remain?  I'm seeing all manner of bad
  behaviour with glthreads - lots of GL_INVALID_OPERATION errors, lots of
  'holds heavyweight lock' errors, the occasional lockup.  It's a mess...

 Ack.

 VTK
 TaskParallelismWithPorts:
 all (inner) triangles of the isosurface are not (wrong) colored
 = R200_NO_TCL fix it

 VTK/bin ./TaskParallelism
 TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion
 `vb.context == ctx' failed.
 Abbruch (core dumped)

 !!! Screen corruption in some upper lines !!!

 Redraw fix it.

 VTK/bin ./TaskParallelism
 TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion
 `vb.context == ctx' failed.
 Abbruch (core dumped)

Still there, even after latest pull (12.03.2003).

-Dieter


---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] reproducible VTK + DRI breakage

2003-03-11 Thread Keith Whitwell
Charl P. Botha wrote:
Dear list,

I've attached a wxPython + VTK example (just the
wxVTKRenderWindowInteractor.py slightly modified) to illustrate the
drmCmdBuffer: -22 bug that I'm actually seeing.  It seems my glthreads.c
attempts were off the track.
In anycase, if you have wxPython and VTK with working Python wrappings
installed, please run the attached example.  Manipulate the 3D cone in both
windows and then close the one window.  Manipulating the remaining 3D cone
for a second or two should result in a drmCmdBuffer: -22 application crash.
If anyone 1. can replicate this or 2. fix it ;) I would be most grateful.

Thanks,
Charl
Charl (and Dieter),

You'll be pleased to hear that I've now got access to a HT enabled box with 
which I can reproduce some or all of the problems you guys have been seeing 
with threaded apps.  Hopefully there'll be some fixes soon.

Keith





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] reproducible VTK + DRI breakage

2003-03-11 Thread Charl P. Botha
On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote:
 Charl P. Botha wrote:
  In anycase, if you have wxPython and VTK with working Python wrappings
  installed, please run the attached example.  Manipulate the 3D cone in both
  windows and then close the one window.  Manipulating the remaining 3D cone
  for a second or two should result in a drmCmdBuffer: -22 application crash.

 You'll be pleased to hear that I've now got access to a HT enabled box with 
 which I can reproduce some or all of the problems you guys have been seeing 
 with threaded apps.  Hopefully there'll be some fixes soon.

Hmmm, new toys to play with!   Thanks for thinking about us. ;)

Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on
my box.  I have not been able to reproduce it since with VTK or
synthetic tests.

Thanks again,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] reproducible VTK + DRI breakage

2003-03-11 Thread Keith Whitwell
Charl P. Botha wrote:
On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote:

Charl P. Botha wrote:

In anycase, if you have wxPython and VTK with working Python wrappings
installed, please run the attached example.  Manipulate the 3D cone in both
windows and then close the one window.  Manipulating the remaining 3D cone
for a second or two should result in a drmCmdBuffer: -22 application crash.
You'll be pleased to hear that I've now got access to a HT enabled box with 
which I can reproduce some or all of the problems you guys have been seeing 
with threaded apps.  Hopefully there'll be some fixes soon.


Hmmm, new toys to play with!   Thanks for thinking about us. ;)

Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on
my box.  I have not been able to reproduce it since with VTK or
synthetic tests.
Can you summarize the problems that remain?  I'm seeing all manner of bad 
behaviour with glthreads - lots of GL_INVALID_OPERATION errors, lots of 'holds 
heavyweight lock' errors, the occasional lockup.  It's a mess...

Keith



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] reproducible VTK + DRI breakage

2003-03-11 Thread Keith Whitwell
Keith Whitwell wrote:
Charl P. Botha wrote:

On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote:

Charl P. Botha wrote:

In anycase, if you have wxPython and VTK with working Python wrappings
installed, please run the attached example.  Manipulate the 3D cone 
in both
windows and then close the one window.  Manipulating the remaining 
3D cone
for a second or two should result in a drmCmdBuffer: -22 application 
crash.


You'll be pleased to hear that I've now got access to a HT enabled 
box with which I can reproduce some or all of the problems you guys 
have been seeing with threaded apps.  Hopefully there'll be some 
fixes soon.


Hmmm, new toys to play with!   Thanks for thinking about us. ;)

Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on
my box.  I have not been able to reproduce it since with VTK or
synthetic tests.


Can you summarize the problems that remain?  I'm seeing all manner of 
bad behaviour with glthreads - lots of GL_INVALID_OPERATION errors, lots 
of 'holds heavyweight lock' errors, the occasional lockup.  It's a mess...
Ah, actually this was my fault.  Missed an installation step on the new box... 
 glthreads is running ok here, now.

Which is good -- but can you still post a summary of outstanding issues.  I 
don't have vtk installed, but will do so if necessary.

Keith



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] reproducible VTK + DRI breakage

2003-03-11 Thread Alan Hourihane

Keith,

Do you want to try running two copies of the 'tunnel' demo ?

Alan.


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] reproducible VTK + DRI breakage

2003-03-11 Thread Charl P. Botha
On Tue, 2003-03-11 at 12:44, Keith Whitwell wrote:
 Ah, actually this was my fault.  Missed an installation step on the new box... 
   glthreads is running ok here, now.
 
 Which is good -- but can you still post a summary of outstanding issues.  I 
 don't have vtk installed, but will do so if necessary.

If we're talking only DRI with your filp-1 changes, I actually have no
outstanding threading problems!  I seem to recall Dieter having a test
case with multiple glxgears and an ipers that broke badly, but he will
probably bring that up again.

On 4.3.0 however, the vtxfmt assert error (and application termination)
seems to happen very often with applications with multiple glxcontexts. 
The problem seems to have been solved in current DRI CVS, but I haven't
been able to track down the fixer/fix (I would love backporting this to
4.3.0).

Thanks again,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] reproducible VTK + DRI breakage

2003-03-11 Thread Michel Dänzer
On Die, 2003-03-11 at 13:51, Charl P. Botha wrote:
 On Tue, 2003-03-11 at 12:44, Keith Whitwell wrote:
  Ah, actually this was my fault.  Missed an installation step on the new box... 
glthreads is running ok here, now.
  
  Which is good -- but can you still post a summary of outstanding issues.  I 
  don't have vtk installed, but will do so if necessary.
 
 If we're talking only DRI with your filp-1 changes, I actually have no
 outstanding threading problems!  I seem to recall Dieter having a test
 case with multiple glxgears and an ipers that broke badly, but he will
 probably bring that up again.
 
 On 4.3.0 however, the vtxfmt assert error (and application termination)
 seems to happen very often with applications with multiple glxcontexts. 
 The problem seems to have been solved in current DRI CVS, but I haven't
 been able to track down the fixer/fix (I would love backporting this to
 4.3.0).

This may be stating the obvious, but RADEON_NO_VTXFMT=1 should work
around the problem, right?


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



---
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] reproducible VTK + DRI breakage

2003-03-11 Thread Charl P. Botha
On Tue, 2003-03-11 at 18:29, Michel Dänzer wrote:
 On Die, 2003-03-11 at 13:51, Charl P. Botha wrote:
  On 4.3.0 however, the vtxfmt assert error (and application termination)
  seems to happen very often with applications with multiple glxcontexts. 
  The problem seems to have been solved in current DRI CVS, but I haven't
  been able to track down the fixer/fix (I would love backporting this to
  4.3.0).
 
 This may be stating the obvious, but RADEON_NO_VTXFMT=1 should work
 around the problem, right?

AFAICR (I don't have my laptop with me) it does. However, I would prefer
to have this done The Right Way(tm).  Someone also sent me your radeon
flushvertices patch that I still have to try on 4.3.0.

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] reproducible VTK + DRI breakage

2003-03-11 Thread Michel Dänzer
On Die, 2003-03-11 at 18:37, Charl P. Botha wrote:
 On Tue, 2003-03-11 at 18:29, Michel Dänzer wrote:
  On Die, 2003-03-11 at 13:51, Charl P. Botha wrote:
   On 4.3.0 however, the vtxfmt assert error (and application termination)
   seems to happen very often with applications with multiple glxcontexts. 
   The problem seems to have been solved in current DRI CVS, but I haven't
   been able to track down the fixer/fix (I would love backporting this to
   4.3.0).
  
  This may be stating the obvious, but RADEON_NO_VTXFMT=1 should work
  around the problem, right?
 
 AFAICR (I don't have my laptop with me) it does. However, I would prefer
 to have this done The Right Way(tm).  

Sure, just pointing out that this isn't a showstopper until the fix is
backported.

 Someone also sent me your radeon flushvertices patch that I still have 
 to try on 4.3.0.

I'd be surprised if that helped this. Keith probably fixed this, look
for his post mesa-4-0-4-branch trunk commits.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



---
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Dri-devel] reproducible VTK + DRI breakage

2003-02-24 Thread Charl P. Botha
Dear list,

I've attached a wxPython + VTK example (just the
wxVTKRenderWindowInteractor.py slightly modified) to illustrate the
drmCmdBuffer: -22 bug that I'm actually seeing.  It seems my glthreads.c
attempts were off the track.

In anycase, if you have wxPython and VTK with working Python wrappings
installed, please run the attached example.  Manipulate the 3D cone in both
windows and then close the one window.  Manipulating the remaining 3D cone
for a second or two should result in a drmCmdBuffer: -22 application crash.

If anyone 1. can replicate this or 2. fix it ;) I would be most grateful.

Thanks,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


A VTK RenderWindowInteractor widget for wxPython.  Note that wxPython
comes with its own wxVTKRenderWindow in wxPython.lib.vtk.  Try both
and see which one works better for you.  

Find wxPython info at http://wxPython.org

Created by Prabhu Ramachandran, April 2002
Based on wxVTKRenderWindow.py



Please see the example at the end of this file.


Creation:

 wxVTKRenderWindowInteractor(parent, ID, stereo=0, [wx keywords]):
 
 You should create a wxPySimpleApp() or some other wx**App before
 creating the window.

Behaviour:

 Uses __getattr__ to make the wxVTKRenderWindowInteractor behave just
 like a vtkGenericRenderWindowInteractor.





# import usual libraries
import math, os, sys
from wxPython.wx import *
import vtk

# a few configuration items, see what works best on your system

# Use wxGLCanvas as base class instead of wxWindow.
# This is sometimes necessary under wxGTK or the image is blank.
# (in wxWindows 2.3.1 and earlier, the GLCanvas had scroll bars)
try:
WX_USE_GL_CANVAS
except NameError:
if wxPlatform == '__WXMSW__':
WX_USE_GLCANVAS = 0
else:
WX_USE_GLCANVAS = 1

# Keep capturing mouse after mouse is dragged out of window
# (in wxGTK 2.3.2 there is a bug that keeps this from working,
# but it is only relevant in wxGTK if there are multiple windows)
try:
WX_USE_X_CAPTURE
except NameError:
if wxPlatform == '__WXMSW__': 
WX_USE_X_CAPTURE = 1
else:
WX_USE_X_CAPTURE = 0

# end of configuration items


if WX_USE_GLCANVAS:
from wxPython.glcanvas import *
baseClass = wxGLCanvas
else:
baseClass = wxWindow

class EventTimer(wxTimer):
def __init__(self, iren):
wxTimer.__init__(self)
self.iren = iren
def Notify(self):
self.iren.TimerEvent()

class wxVTKRenderWindowInteractor(baseClass):

A wxRenderWindow for wxPython.
Use GetRenderWindow() to get the vtkRenderWindow.
Create with the keyword stereo=1 in order to
generate a stereo-capable window.

def __init__(self, parent, ID, *args, **kw):

# private attributes
self.__OldFocus = None

self.__RenderWhenDisabled = 0

# First do special handling of some keywords:
# stereo, position, size, width, height, style

stereo = 0

if kw.has_key('stereo'):
if kw['stereo']:
stereo = 1
del kw['stereo']

position = wxDefaultPosition

if kw.has_key('position'):
position = kw['position']
del kw['position']

size = wxDefaultSize

if kw.has_key('size'):
size = kw['size']
del kw['size']

if kw.has_key('width') and kw.has_key('height'):
size = (kw['width'], kw['height'])
del kw['width']
del kw['height']

# wxWANTS_CHARS says to give us e.g. TAB
# wxNO_FULL_REPAINT_ON_RESIZE cuts down resize flicker under GTK
style = wxWANTS_CHARS | wxNO_FULL_REPAINT_ON_RESIZE

if kw.has_key('style'):
style = style | kw['style']
del kw['style']

# the enclosing frame must be shown under GTK or the windows
#  don't connect together properly
l = []
p = parent
while p: # make a list of all parents
l.append(p)
p = p.GetParent()
l.reverse() # sort list into descending order
for p in l:
p.Show(1)

# initialize the wxWindow
baseClass.__init__(self, parent, ID, position, size, style)

# create the RenderWindow and initialize it
self._RenderWindow = vtk.vtkRenderWindow()
try:
self._RenderWindow.SetSize(size.width, size.height)
except AttributeError:
self._RenderWindow.SetSize(size[0], size[1])
if stereo:
self._RenderWindow.StereoCapableWindowOn()
self._RenderWindow.SetStereoTypeToCrystalEyes()

self.__Created = 0
# Tell the RenderWindow to render inside the wxWindow.
if self.GetHandle():
self.__Created = 1
self._RenderWindow.SetWindowInfo(str(self.GetHandle()))