[gl4java-usergroup] Re: It's official, Solaris is a pain in the....

[Kenneth B. R. <kbr...@al...>]

> Don't get me wrong, I learned a while back that the GLContext is not
> created until the display areas are visible and realized first (a VERY
> annoying feature of all Java bindings of OpenGL).

How else should this behave? You won't be able to do any drawing
until the window is realized because glXMakeCurrent and variants
on other OSs require the widget to be passed. OpenGL for Java
gives you an init routine which lets you set up first-time OpenGL
state for a given context.


> Now, you would ask, "Well, what was in those 5 lines you skipped above?"
> Answer: a second GL4Java display and our Java3D display. So, we learned
> another hard lesson. Construct all your display windows (GL4Java and
> Java3D) including the creation of your GLCanvases *before* you make any
> of them visible on Solaris.

This isn't a Solaris issue. In general the link between the Java
binding for OpenGL and the AWT is the least stable. There are a
lot of reasons for this, including that the AWT is inherently
multithreaded (events are dispatched on the AWT thread) and
OpenGL inherently has a single-threaded rendering model. In my
opinion the now-defunct Magician binding probably had the fastest
and most robust window system link (including, to the best of my
understanding, support for hardware-accelerated rendering to
Swing widgets.) It's on my list of things to do to revisit the
OpenGL for Java code in this area and try to simplify it to make
it more robust, though doing so may require backward-incompatible
API changes so it will probably be for version 3.0.


> Here is another piece of evidence that Solaris has problems... We also
> moved the setVisible(true) call for our Java3D display down 5 lines to
> its original location. When we do this, Solaris makes that window a
> Frame (when we clearly are creating a JDialog in the code). If we move
> the setVisible(true) back up the 5 lines, then Solaris makes it a
> JDialog. *LOL* We can tell because it adds the two little window buttons
> in the upper right on the window title bar when it is a Frame. Talk
> about flakey!! The code always calls for a JDialog, but moving the call
> to setVisible(true) on the Java3D before the GL4Java windows are
> setVisible(true) causes Solaris to decide it would rather give us a
> Frame for the Java3D window.

I have no idea whether the code implementing this could be in
Swing, the X11 implementation of the AWT, or in Java3D code, but
it sounds like a bug. Please boil this down into a test case and
file it on the Java Developer's Connection at
http://developer.java.sun.com/ . Make sure to test with 1.4
before you do to ensure it hasn't already been fixed. A huge
number of improvements went into Java2D, the AWT, and Swing in
1.4, and despite the Java3D interactions the window system is
much faster and more robust than in 1.3.1.


> PS. A month back when we were struggling with this problem (one of many
> sessions), we got the Java compiler to crash on Solaris. We commented
> out one simple line in our source code, then the javac would crash every
> time when parsing the code. We uncomment that line, then the javac
> worked fine. I wouldn't have believed that one if I didn't see it with
> my own 2 eyes. *L*

Please file a bug if something like this happens.