Solaris / jogl 1.0.0 graphics glitch

[itomeshi]

I’m having a bit of a problem with a jogl-developed tool, and was looking for a bit of insight. It probably isn’t something that anyone here would have a quick-and-dirty fix for, but I just need a nudge in the right direction.

I’m building an application that uses Substance LAF for themes, and both Java3D and Jogl for running third-party developed 3D tools. It’s an MDI application using JInternalFrames. We have a 2D plot tool and 3D map (both in Jogl) and a ‘cube’ for switching desktops that uses Java3D and is not in a JinternalFrame.

On Linux, everything looks great, and performance is acceptible, even on the low-end development machines with Intel Integrated Graphics.
On Solaris, the plot and cube appear OK, but the map does not. It’s GLJPanel takes up the whole JInternalFrame, but about a third of it on the right side has various graphical glitches - it’s all black, sometimes shows a copy of the image on the globe, sometimes a distorted and/or discolored version of the texture.

The truly odd part is, if I stick the map in a JInternalFrame in a test app that has Substance LAF enabled, I don’t have the problem.

No exceptions or GL errors are being thrown, at least that I’ve seen, and our Solaris machines DO have hardware 3D acceleration - I don’t have specs in front of me, but I know that they do. They were able to run a previous version of the map - which was heavyweight and using jogl 0.9.0 - without any issue.

I know that 1.0.0 isn’t the latest version of jogl, but I’m not sure if these components could use a newer version without significant modification.

So, does anyone have any ideas? Any VM arguments that may give me more info, any known Solaris bugs, that sort of thing? Has anyone seen anything like this before?

[itomeshi]

I have a bit more information. Still pretty well stumped, but hopefully this will give someone a spark.

• Solaris OpenGL Patch - We were originally running 113886-21, but just tried upgrading to 113886-47 (released Sept. 19). It didn’t help.
• Video cards - We’re running on XVR-1200. We support other cards, but do not have them to test on.
• OS Version - We’re running on Solaris 9.
• Drawable Shape - The old version of the map was confined to a square. The new version is not. Problems drop DRAMATICALLY when the canvas is close to a square, and even more so when it starts out as a square instead of a rectangle.
  [li]Parent Frames - On a JFrame, even in our application, we don’t have any problems. Problems only seem to arise when the GLJPanel is in a JIDE (ugh!) Docking Frame or a JInternalFrame. I’m wondering if this points to a window handle issue - this certainly wouldn’t be the first time we’ve had issues with that. Java 1.6 and below gives JInternalFrames new window handles much more often than necessary - I’m not sure if it happens when it comes on top, but I’m certain it happens when it’s restored from a minimized state.

I’m going to try to use a newer version of JOGL - probably both 1.1.0 and the 1.1.1 beta - to see if it can help. I’m not sure if it is compatible with our other tool, however. Is there any way to run multiple versions of JOGL in the same JVM?

[kbr]

These sound like OpenGL driver problems, I’m sorry to say (especially as a Sun employee). If you have a support contract, you should raise them. We did have some bugs in earlier versions of JOGL around our Texture utility classes not working on older OpenGL implementations, but at this point those problems should be fixed, and I don’t think that’s what you’re running into.

You can use two different versions of JOGL in the same JVM if you load them in different class loaders. JOGL-based applets do this implicitly because the Java Plug-In is responsible for the class loader management. For a standalone application you will need to do more work and basically do your own class loader management. If you’re even picking up JOGL from the application class path then you won’t be able to load two versions simultaneously.

[itomeshi]

@Ken Russell

These sound like OpenGL driver problems, I’m sorry to say (especially as a Sun employee). If you have a support contract, you should raise them. We did have some bugs in earlier versions of JOGL around our Texture utility classes not working on older OpenGL implementations, but at this point those problems should be fixed, and I don’t think that’s what you’re running into.

From what I’ve seen so far, this seems realistic. I was in this weekend and tried putting in both versions. While 1.1.1 rc6 has the same issue on Solaris, 1.1.0 works great without any distortion - except on the machine that we took to Sun OpenGL patch 113886-47.

Meanwhile, 1.1.0 on Linux complains about a glibc 2.4 requirement. We’re running CentOS 4.x, which only has glibc 2.3.4. I’ll most likely recompile on that platform within the next week or so, but as a quick fix I’m using the 1.1.1 rc6 .so libraries with 1.1.0 jars on Linux, and they work fine.

[quote]You can use two different versions of JOGL in the same JVM if you load them in different class loaders. JOGL-based applets do this implicitly because the Java Plug-In is responsible for the class loader management. For a standalone application you will need to do more work and basically do your own class loader management. If you’re even picking up JOGL from the application class path then you won’t be able to load two versions simultaneously.
[/quote]
We currently use the application class path, but we have a web ‘portal’ that loads it - we can modify the classpath there. That was the approach we were going to take until we saw the machine with OpenGL patch 47 continue to fail. At this point, we’re going to try to selectively downgrade that patch until we find the newest that works - if in fact that is the problem.

We also have a few other things to try - JDK update to 1.6.0 u01, check for libc updates, etc. - but at this point we tend to agree that it is a driver issue. I’m going to check with our Solaris admin - if I can ever find him! - and take that approach as well.

Thanks for the help, and your openness about it potentially being a Solaris driver issue. We have other Solaris issues - it seems to be a solid platform, but a bit fragile on updates and somewhat slow performance. I think a big part of the performance issue is the age of and drivers for the XVR-1200 and XVR-600 graphics cards. In many ways this application pushes the envelope in terms of graphics - Substance skinning, transparency via JXPanels, and window frame animation - but even with those disabled, these glitches still occur.

Shawn

[itomeshi]

Well, after finally getting my Solaris admin tp try updating patches, we’ve confirmed that 21-24 work, and that 25+ all fail, including the latest, 47.

I’ve looked at the patch notes for 113886-25, and found something interesting in one of the fixes:

5069430 with OpenGL application under CDE, windows are not repainted correctly

At this point, I would believe that to be what likely broke it, since the other fix is unrelated. I know some of our machines use Gnome on Solaris, but that most people use CDE. I’m going to see if there is any relation between WM and the bug, but beyond that as a short-term and embarassing fix we’re resizing the window to be square, which helps somewhat.

We’re going to try to pursue it via our Sun agreement, but that may take some time and we ship far too soon. If you have any ideas or contacts that may help, please let me know.

[kbr]

If you can email me at kenneth dot russell at sun dot com I can put you in touch with the Solaris OpenGL team.