[vtkusers] Problems with the window created in vtkPanel.java

[Wiggins]

I have been converting a vtk-based app. originally done in Tcl/Tk, to
Java.  Most of the time, I use SGI workstations.  I found a problem on
my O2: the vtkPanel remained the color of the background defined for the
Canvas from which vtkPanel is derived.  On several other SGI machine
types, the 3D graphics was drawn OK but some of them clearly didn't use
double buffering, so the image flickered as it was rendered and
rerendered.

With lots of help from SGI, I have come to understand that the problem
is with the visual attached to the window created by Java for the
vtkPanel.  On the O2, the window has a visual that just isn't
appropriate for OpenGL rendering.  On an Octane, the window may be only
single buffered.

It seems impossible to rely on Java to always provide exactly the right
kind of window for vtk rendering.  How can it know what we want?  There
seems to be no way to tell Java what your canvas will be used for.  So I
think vtk needs to be a bit more active in insisting on the right kind
of window.  If you simply hack the vtkOpenGLRenderWindow code a little
to make a new standalone double-buffered, 24 bit window, then it renders
beautifully.  I can even get the window to overlay the one created by
Java for vtkPanel, but it doesn't get the events it should.

Can some of you who know X, OpenGL, Java, and other esoteric religions
offer some opinions about how this should be handled and whether it
would be possible to have vtk create a window to its own liking and
retrofit it into the Java Components properly without violating the
multitude of warnings about not tinkering with Java ComponentPeers??

By the way, for those of you trying Linux and vtk, I just got vtk to run
on a Dell C800 laptop with RedHat 7.0 by upgrading to XFree86 v4.0.2 as
mentioned here a few weeks ago.  No other problems, just build with 

--with-shared --with-tcl --with-tkwidget --with-java --with-local
--with-contrib ... whatever

I don't think you need either --with-opengl or --with-mesa unless you
are doing offscreen rendering or otherwise need to bypass the nice
configuration of X/OpenGl that's set up for you.


-- 
Wendell Wiggins 
jwiggins at enter.net