WWJ and Platform-dependence

[smcnaughton]

I'm evaluating using WWJ in a large application to replace an older, in-house developed map. I have a few questions that I'd like to see if anyone has dealt with in the past.

If anyone has any experience with any of the following situations, could they please just report a bit on any success or roadblocks they may have run into? It would be greatly appriciated, as I've been handed the dreaded 'schedule of doom'. When given the assignment, I'm already listed as 'behind schedule'. :mad:

1) Officially, WWJ looks as if it supports Windows, MacOSX, and Linux (at least most newer flavors). The application I'm working on must support Solaris as well - has anybody tried WWJ on Solaris, on both Intel and Sparc platforms? Can you plug in JOGL libraries for different OSes?

2) WWJ also mentions support for NVidia, ATI, and Intel graphics cards. Are there any significant caveats on any of these, and is there any support for other cards, such as the Sun XVR-1200 (http://www.sun.com/desktop/products/graphics/xvr1200/index.html)?

3) Our application currently uses an in house map that also uses JOGL. There is also another component in our app which uses Jogl. Has anyone noticed incompatiblity between components that use JOGL?

4) Our application uses Substance (https://substance.dev.java.net/) LAF to have a 'more pleasing'' GUI. Has anybody tried using it with any LAF replacement and specifically Substance?

5) Is WWJ's WMS support in a usable state?

6) Does WWJ run well on JDK/JRE 1.6? I've seen primarily mentions of 1.5.

7) Can WWJ be used in a JInternalFrame? Is it lightweight or heavyweight?

[Ken Russell]

I can answer only a couple of these. I've tested WWJ on Solaris/x86 10 with NVidia graphics hardware and the new drivers from NVidia for Solaris/x86 and it runs well. To be honest I doubt that it will run on Solaris/SPARC as the graphics hardware on that platform is a couple of generations old and I think WWJ relies on some fairly recent OpenGL extensions. I've found that WWJ works well on all of NVidia, ATI and Intel graphics chips.

tag, pmurris and others can comment on interoperability with other JOGL code, but in general, as long as you can run the other JOGL component with the latest version of the JOGL library, then everything should work fine.

WWJ runs great on Java 6.

There are enough issues with JOGL's lightweight GLJPanel (mea culpa) that the strong recommendation is to only use WWJ as a heavyweight component. This does mean that WWJ won't currently play well with JInternalFrames, but that's about the only situation where it can't be made to interoperate well with Swing components.

[tag]

Ken is the proverbial horse's mouth -- note I said "mouth" -- on jogl portability, and he's done a great job of addressing that. WWJ is intended to run on Mac, Linux, Windows and Solaris, although we don't test first-hand on the latter. It so far seems to run on all modern, mainstream graphics hardware, even the wimpy Intel thing in Macbooks and cheap laptops. Some sytems need a driver update, though.

The only hardware problems we've noticed are some artifacts on the new iMacs with the ATI Radeon HD 2600. There are some occasional, transient black lines between image tiles when high-res tiles are loading, as though a row of texture pixels gets dropped. This could very easily be WWJ's problem, but we haven't investigated yet. The problem also shows up to a lesser degree on Macbooks.

We have seen apps that use JOGL in conjunction with WWJ. That's a requirement of the WWJ design. But if multiple components are using JOGL and drawing to the same window, they'll have to synch up on display events -- the callbacks from GLAutoDrawable. I'd be interested to know if problems occur when using JOGL to several different windows (several different graphics contexts). My guess is there wouldn't be any -- the JOGL libs are amazingly correct and stable.

WWJ's client support for WMS is in a very usable state. The next release will have some performance improvements and will be using WMS for the main WWJ image layers (BMNG, i3Landsat, etc.) In fact, there will even be a WMS server in the next release. One thing currently missing in WWJ's WMS support is parsing of Dimension elements, but that will be added soon. It also currently assumes that WMS servers support requests for arbitrarily sized images.

WWJ runs well on J5 and J6. Only J5 is supported by Apple, so we have to run well there. (We develop primarily with Macs.)

Sounds like fun! ' Hope it works out.

[zerobarrier]

I've compiled and tested WWJ against both 1.5 and 1.6 with no problems at all. If you don't have a requirement to run against 1.5, 1.6 is recommended due to a number of OpenGL rendering enhancements.

As Ken said, the lightweight GLJPanel component is buggy, so I would stick with the heavyweight component. However, this doesn't prevent you from using lightweight Swing components. You could, for example, place two heavyweight components in a JLayeredPane (one being the heavyweight GL component) and use Swing components on the top layer. This would ensure your Swing UI would be rendered after the native GL rendering. JInternalFrame is a Swing component that is indeed lightweight, which means you'll have to wait until 1.7's lightweight/heavyweight component mixing feature. Here's a quote from Sun: "Do not place heavyweight (AWT) components inside a JInternalFrame."

[fabrizio.giudici]

1) Depends on the context.

3) I'm using JOGL for other purposes in the same application and there were no problems.

4) My application on MAc OS X runs with Quaqua which is a LAF replacement, and on Windows/Linux with Nimrod. No specific LAF problems so far.

6) I'm running it on Java 6 with Linux and Windows, no problems seen so far.


PS I've been silent for a while because I've focused on some required parts of my applications that are not related with WWJ, but I'll resume working on it soon. See you later!

[fabrizio.giudici]

Whoops, sorry, forgot to complete reply #1.

Depends on the context. For instance, with NetBeans RCP I have problems with Solaris since RCP expects to have all the native libraries placed in the same directory. Unfortunately, this creates name conflicts (e.g. between the Linux and Solaris binaries). But this is a problem of NetBeans RCP and not of WWJ (there are workarounds anyway). Just check the technology you're using whether it puts constraints about native libraries deployment.

[toolshed]

There are enough issues with JOGL's lightweight GLJPanel (mea culpa) that the strong recommendation is to only use WWJ as a heavyweight component. This does mean that WWJ won't currently play well with JInternalFrames, but that's about the only situation where it can't be made to interoperate well with Swing components.

For those of us who are in dire need of the lightweight widgets:

Our team has been developing almost exclusively now with WWJ rendering on the GLJPanel. We have finally found the right VM settings (-Dsun.java2d.opengl.fbobject=false and -Dsun.java2d.opengl=true) for acceptable performance. In fact, the performance on the GLJPanel is noticeably faster than the GLCanvas when testing each on the same platform.

[fabrizio.giudici]

That is, you're saying that with the above settings we can use the GLJPanel with no worse performance than the GLCanvas and have no rendering problems? It would be excellent news.

[toolshed]

That is, you're saying that with the above settings we can use the GLJPanel with no worse performance than the GLCanvas and have no rendering problems? It would be excellent news.

Well, sort of. I'm saying that currently on my graphics hardware with those settings that I am seeing better performance with the GLJPanel than with the GLCanvas.

[smcnaughton]

Sorry for the slow reply - on our end (as a contractor), we've been weighing options.

I can answer only a couple of these. I've tested WWJ on Solaris/x86 10 with NVidia graphics hardware and the new drivers from NVidia for Solaris/x86 and it runs well. To be honest I doubt that it will run on Solaris/SPARC as the graphics hardware on that platform is a couple of generations old and I think WWJ relies on some fairly recent OpenGL extensions. I've found that WWJ works well on all of NVidia, ATI and Intel graphics chips.

This is realistically my biggest problem. We have XVR-600s and XVR-1200s on the target machines. I was able to run on a system with one of these cards, and got an exception (which I'll try to add the exact text of later) that essentially said that the graphics card did not support textures of the format WWJ was feeding it. I was also getting severe infinite loop lockups. They left the mouse cursor moveable but stuck, and I couldn't interact with GNOME at all. I could SSH in from another machine, but I couldn't even kill -9 the WWJ process! I had to hard reboot the machine.

We're currently investigating what upgrade options are available for these machines, but our client is both absolutely set on WWJ and simultaneously running 80% of this app's users on machines that will not support WWJ in their current configuration. I have an XVR-2500 I'm trying to get access to test it on, but at this point I have little faith in the XVR series being able to run World Wind.

I guess the ultimate question is, what's the easiest way I can determine whether or not a given graphics card will run WWJ? Is there any way to get a list of the GL Extensions and capabilities that WWJ uses? Furthermore, given a card installed in a machine, is it possible to dump it's capabilities on Solaris, where glx_gears, etc isn't installed?

[smcnaughton]

For those of us who are in dire need of the lightweight widgets:

Our team has been developing almost exclusively now with WWJ rendering on the GLJPanel. We have finally found the right VM settings (-Dsun.java2d.opengl.fbobject=false and -Dsun.java2d.opengl=true) for acceptable performance. In fact, the performance on the GLJPanel is noticeably faster than the GLCanvas when testing each on the same platform.

I'm going to experiment with these settings in both our current map and WWJ when I can get it working. We almost absolutely need a lightweight map - we use JInternalFrames heavily, and can't wait for JDK7 to be released and tested, etc. If we can't have a lightweight map, we'll need to be able to 'switch it off' when it's not in the topmost window. We originally tried this, and it's an arduous task.

I've tested WWJ on two systems. The Solaris/SPARC would occasionally pop up a star field, atmosphere (with map reflection), but no globe. The Linux machine with Intel graphics wouldn't load and probably needed a driver update.

[smcnaughton]

I've had a chance to do a bit more testing, and I found some interesting discrepancies.

I gained access to a Solaris/SPARC machine with an XVR-2500 video card and was planning on testing as I have been - running the AWT1Up class from the worldwinddemo package - but did not have access to a JDK. Instead, I ran the prepackaged demo, and it ran - globe and all! It still did completely lock the system after a minute or so, but this was unexpected.

As a control, I tested the prepacked demo on the machine I had been using previously. It's equipped with the lower end XVR-1200 video card, and still ran! I closed it before it had a chance to freeze up for me.

To get it running, I had manually set the java.library.path to a folder containing the SPARC Jogl native libraries. We're using the latest version (1.1.1rc6) for our app, and it matches what's inside WWJ 0.4.1. At this point, if I can get rid of the complete lockups, WWJ may be usable. I guess that leaves me with a couple of questions:

1) Is the AWT1Up demo in the worldwinddemo package in a usable state?
2) Has anyone experienced lockups like I've described?

Edit:
I'm had a chance to test WWJ on a machine with a real video card (NVidia, model unknown). It's a Linux box but running a x86_64 kernel, which the demo complains about not being able to find a valid .so file for. There is no official x86_64 JOGL precompiled binary. Should we do a custom build, or is there an easier workaround?

[patmurris]

I'm being told the X11 lockup problem has been fixed.

For which version of java is the GLJPanel working - 1.6?

[Ken Russell]

@smcnaughton: when the lockup occurs, does the entire X server freeze, or just the World Wind Java app?

The bug patmurris indicates is fixed was a deadlock bug in WWJ where it was attempting to do AWT / Swing work from inside a JOGL GLEventListener callback, which isn't portable and which can cause deadlocks on X11 platforms due to how JOGL has to do its locking on these platforms.

However, this bug shouldn't cause the X server to lock up.

If it's possible for you to remotely log in to the machine when the lockup occurs and use the jstack tool out of the JDK against the PID running WWJ to get a thread dump, that would be helpful. If you can't even log in to the machine remotely once the lockup occurs, that would indicate an even deeper problem in the software stack and would be useful information.

I have seen hangs of WWJ on my Solaris/x86 machine with NVidia graphics and the new NVidia drivers for Solaris/x86, but they were caused by the deadlock problem above; it has never hung the X server.

[Shadre]

So, we have a nice Solaris 10 machine with an XVR-2500 on it. I attempted to patch the OS up to the latest Sun OpenGL release (1.5) and patch the video card drivers to max as well.

I get a repetitive exception that :

javax.media.opengl.GLException: DXTn compressed textures not supported by this graphics card
at com.sun.opengl.util.texture.Texture.chec kCompressedTextureExtensions(Texture.jav a:928)
at com.sun.opengl.util.texture.Texture.upda teImage(Texture.java:482)
at com.sun.opengl.util.texture.Texture.upda teImage(Texture.java:358)
at com.sun.opengl.util.texture.Texture.<init>(Texture.java:159)
at com.sun.opengl.util.texture.TextureIO.ne wTexture(TextureIO.java:446)
at gov.nasa.worldwind.layers.TextureTile.in itializeTexture(TextureTile.java:253)
at gov.nasa.worldwind.layers.TextureTile.bi nd(TextureTile.java:286)
at gov.nasa.worldwind.render.SurfaceTileRen derer.renderTiles(SurfaceTileRenderer.ja va:174)


And then the compass will display, but the earth will not display. Any ideas of what is wrong with my setup vs. yours?

[smcnaughton]

@smcnaughton: when the lockup occurs, does the entire X server freeze, or just the World Wind Java app?

The bug patmurris indicates is fixed was a deadlock bug in WWJ where it was attempting to do AWT / Swing work from inside a JOGL GLEventListener callback, which isn't portable and which can cause deadlocks on X11 platforms due to how JOGL has to do its locking on these platforms.

However, this bug shouldn't cause the X server to lock up.

If it's possible for you to remotely log in to the machine when the lockup occurs and use the jstack tool out of the JDK against the PID running WWJ to get a thread dump, that would be helpful. If you can't even log in to the machine remotely once the lockup occurs, that would indicate an even deeper problem in the software stack and would be useful information.

I have seen hangs of WWJ on my Solaris/x86 machine with NVidia graphics and the new NVidia drivers for Solaris/x86, but they were caused by the deadlock problem above; it has never hung the X server.

I'm seeing entire X server lockups. I can SSH into the machine after the lockup; while SSHed in, I've tried both jstack and just kill -9 on the WWJ process. JStack and JConsole both cannot connect to the target VM. Kill -9 does nothing.

This lockup has occured on every machine I've tried WWJ on. Solaris/SPARC with XVR-1200 tends to lockup either instantly or after 2-3 minutes. It has a high tendancy to lockup if I try to close the window. Linux/P4-x86 with Intel graphics on CentOS isn't as bad - it will lockup, typically after 5-10 minutes, and I can often close the window. The lockup is worse there, however - I typically can't SSH in.

These are machines without internet access, so it could be related to that. The source-base AWT1Up demo seldom works at all, so I can't test Offline Mode.

[smcnaughton]

So, we have a nice Solaris 10 machine with an XVR-2500 on it. I attempted to patch the OS up to the latest Sun OpenGL release (1.5) and patch the video card drivers to max as well.

I get a repetitive exception that :

javax.media.opengl.GLException: DXTn compressed textures not supported by this graphics card
at com.sun.opengl.util.texture.Texture.chec kCompressedTextureExtensions(Texture.jav a:928)
at com.sun.opengl.util.texture.Texture.upda teImage(Texture.java:482)
at com.sun.opengl.util.texture.Texture.upda teImage(Texture.java:358)
at com.sun.opengl.util.texture.Texture.<init>(Texture.java:159)
at com.sun.opengl.util.texture.TextureIO.ne wTexture(TextureIO.java:446)
at gov.nasa.worldwind.layers.TextureTile.in itializeTexture(TextureTile.java:253)
at gov.nasa.worldwind.layers.TextureTile.bi nd(TextureTile.java:286)
at gov.nasa.worldwind.render.SurfaceTileRen derer.renderTiles(SurfaceTileRenderer.ja va:174)


And then the compass will display, but the earth will not display. Any ideas of what is wrong with my setup vs. yours?

I've had that exact error when using the source-based AWT1Up demo in the worldwinddemo package. It freezes up as well, and will not display the earth, but will draw the starfield, atmosphere, etc. Occasionally, it gives me a distorted earth texture in the atmosphere/fog layer, but not always. At this point, I'd just like to get something up and running. :)

I'm actually wondering if part of the difference is that the precompiled demo may be a bit more forgiving to the lack of an internet connection and automatically switch to offline mode. I didn't see any code to do so in the AWT1Up demo, but trying to modify it to do so didn't seem to make a difference.

I'm going to try on both Linux and Solaris/X86 machines that have NVidia cards this afternoon. I'd like to see if they crash.

I'm using JDK/JVM 1.6 on Linux (some machines have an update, like 1.6.0_04, some don't), so I may try JVM 1.5 to see if that makes a difference. Solaris tests are done with JVM 1.5, so I may try 1.6 on them.

Performance on the XVR-1200 is really bad on both the current JOGL-based map (which does not have hi-res textures, but does plot a large bumber of data points) and WWJ (for the 2-3 minutes it runs on 40-60% of WWJ demo starts), so I've been working with a Sun engineer (James Woods?) on trying to improve performance. Ken, he may try to get in touch with you today about the exact GL extensions being used.

As for why we're so adamant on using WWJ, it's primarily our customer. At my development site, our opinion is that WWJ is better than our current, internal, end-of-life'd map if the issues can be worked out. However, our customer has DEMANDED the use of WWJ, even though a 2D mapping solution would fit their needs (between plotting capability and performance/stability on primarily Solaris/SPARC systems).

My other concern, once the stability and empty map performance issues are worked out, is how well WWJ can handle large numbers of points. Internally, we're trying to develop an R-Tree-based solution to limit the number of actual points on the map, but in terms of actual points plotted via latitude and longitude we need to hit 50,000+ points today and a million (yes, a million :rolleyes:) within a year or so. On Solaris/SPARC. :eek: How much of this will be our data-point merging tool and how many actual points the map will need to handle natively remains to be seen. I saw an old thread about a 'LotsOfIcons' layer (http://forum.worldwindcentral.com/showthread.php?t=11314) - did that ever get integrated into the baseline?

[patmurris]

My other concern, once the stability and empty map performance issues are worked out, is how well WWJ can handle large numbers of points. Internally, we're trying to develop an R-Tree-based solution to limit the number of actual points on the map, but in terms of actual points plotted via latitude and longitude we need to hit 50,000+ points today and a million (yes, a million :rolleyes:) within a year or so. On Solaris/SPARC. :eek: How much of this will be our data-point merging tool and how many actual points the map will need to handle natively remains to be seen. I saw an old thread about a 'LotsOfIcons' layer (http://forum.worldwindcentral.com/showthread.php?t=11314) - did that ever get integrated into the baseline?
Dealing with larger numbers of renderables is an issue with the current SDK alpha version. There are a number of related posts where users have tackled the problem from various perspectives, often with custom code. The LostOfIconsLayer is one of them and has helped many here. However, a more solid and generic scene graph or tree based approach remains to be implemented into the SDK.

[smcnaughton]

In researching some of these issues, I've found a couple of interesting things.

On Solaris/SPARC compatibility:

The SPARC machines we have (Sun Blade 2000 and 2500, primarily) use PCI-X (not PCI Express) graphics. They can only use three different video cards: XVR-100, XVR-600, and XVR-1200. All of these, as well as the XVR-2500 Shadre tested on, are based on the old 3DLabs Wildcat chips. The WorldWind wiki shows extremely limited support for these cards on the Video Card Compatibility page. While I assume this is for WW.NET, how close is WWJ in terms of video card usage?
The Sun engineer I spoke with, James Woods, gave me a system environment variable to try with the XVR-1200. These cards are dual-GPU, and each GPU has a 128MB bank of VRAM for textures. By default, these are mirrored. To combine them into a single memory bank, set SUN_OGL_JFB_GLOBAL_TEXTURE_MODE to 1. Note that this causes a small delay in VRAM texture pulls if one GPU has to pull from the other GPU's memory, but when dealing with a large number of textures is MUCH faster than disk access (if this is actually occurring). In practice, I saw no real improvement in a situation where I was *not* receiving any hi-res imagery. I have yet to test it on a system where I am receiving imagery. (I don't have access to anything Solaris outside of my secure area, because no one *uses* Solaris outside of a secure area. I'm going to need to pull some strings.)


On system lockups:

I finally got access to functional machines with NVidia graphics (Quatro FX 3450 series, IIRC) and ran the ApplicationDocument demo (what I've been referring to as precompiled).
Linux/x86 with the Nvidia card was extremely fast and didn't crash after 15-20 minutes of playing around with it, opening and closing windows, etc. I like the WWJ user experience on it - even the Annotation demo ran faster than what I've gotten on the SPARC/XVR-1200 machines. There is, however, a hiccup when rotating and going over the US - I think it has something to do with the USGS Ortho Imagery Layer being enabled but not accessible, but I'm not entirely sure.
Solaris/x86 doesn't appear to crash either. It's MARKEDLY slower than the Linux test box (even with a Quatro FX 3450), and these have identical hardware configurations from what I can tell. I'm willing to chalk that up to immaturity in the Solaris NVidia drivers. We had a heck of a time actually getting it running, and had to play around with the runtime linking environment. In fact, we nearly murdered one Solaris box!
I'd like to limit it to Solaris/SPARC, but the crashes I've seen on my own Linux box still bother me. I'm going to try some other Linux boxes with configurations similar to mine, and see if the same crashes occur.
If the similar crashes occur, I'm going to lean towards it being a conflict involving low-end graphics (ie, XVR/Wildcat or Intel) and a lack of network connectivity while not in Offline Mode. Again, this is just a guess, but it's the only pattern I've seen so far.

[smcnaughton]

Well, in further testing on the Linux/X86/NVidia box, one of my colleagues was somehow able to get the ApplicationDocument to fail. It wasn't the same crash. He somehow set the view angle to an invalid value, such that you could not see the globe. It almost immeadeatly ran out of heap space and killed the JVM. It did not lock up the machine, so I'm thinking it's unrelated.

As for the Solaris/SPARC issue, I've found out that DXTN aka S3TC is simply unsupported. My understanding is that DXTN is S3TC, and the name is from when S3TC was added to the DirectX 6.0 standard? It seems the biggest issue is license cost to S3. S3's Savage cards are dead, Chrome cards are unpopular, but S3TC is a moneymaker. Since the XVR-600 and XVR-1200 are end-of-life, there's little chance of an update. For the XVR-2500, it can be brought up to the product manager, but considering how the majority of 3D apps on Solaris/SPARC are CAD and there is no need to support DirectX (since these cards are only for machines that can never run Windows), it's not looking good.

I found a thread in the JOGL forum (http://www.javagaming.org/forums/index.php?topic=16858.0) that details a previous WWJ and XVR card effort, this with a XVR-2500. I'm not an OpenGL expert, but what I get from that conversation is the only compressed texture format included is ARB, via GL_ARB_Texture_Compression (http://www.opengl.org/registry/specs/ARB/texture_compression.txt). I'm not sure how practical for WWJ this format is or how hard the code change would be. I'm thinking it be major, since this NVidia page (http://developer.nvidia.com/object/texture_compression_OpenGL.html) leads me to believe that the DDS texture files (from cache packs, for example) are already S3TC/DXTN compressed, so would it require a software (CPU-based) decompressor and then either ARB compression (more CPU) or being sent uncompressed (increased video card bandwidth and memory use).

Since we have to support these XVR cards, this pretty much prevents our use of WWJ. I'm still pursuing options - James Woods mentioned he was going to talk to Pat and Ken to see about a test build without compressed texture support - but even that would have a large set of problems (performance hit, different branch, etc).

[Shadre]

JWW's DDSConverter.java is used to convert various image formats to DXT1 and DXT3 in JWW. This is a CPU-software based transform, I think written by tag. I recently posted to the forum a link on how to do image/texture to DXTN via JOGL.

You could build a parallel to DDSConverter for "ARB", or maybe, my link could be asked to do an "ARB" compression? Not running the experiement, but you can. Here is the link again.


http://jsourcery.com/api/java.net/jogl/1.1.0/demos/texture/TextureConvert.source.html

[smcnaughton]

JWW's DDSConverter.java is used to convert various image formats to DXT1 and DXT3 in JWW. This is a CPU-software based transform, I think written by tag. I recently posted to the forum a link on how to do image/texture to DXTN via JOGL.

You could build a parallel to DDSConverter for "ARB", or maybe, my link could be asked to do an "ARB" compression? Not running the experiement, but you can. Here is the link again.


http://jsourcery.com/api/java.net/jogl/1.1.0/demos/texture/TextureConvert.source.html

That's a pretty good code snippet, but it does raise a couple of questions. First off, I still can't tell if ARB is actually compressed or just stored. If the latter, that's going to have a performance penalty. I'm pretty sure ARB stands for 'Array Buffer', but what that actually means to me, I'm not really sure.

Secondly, I wonder what all would need changed in WWJ to pass the ARB-compressed textures over, if any. I'm not familiar with the WWJ code, so I'd not really know where to start.

Third issue is figuring out what to put in the 'inputData.setInternalFormat' line. I think I know the extension to check for (GL_ARB_texture_compression), but what I don't know is the ARB equivalent of 'GL_COMPRESSED_RGBA_S3TC_DXT3_EXT'. I didn't see any 'GL_COMPRESSED_' mentioning ARB in the jogl docs, so that leads me to believe that it may not be a compressed format after all. Then again, I'm by no mean a OpenGL coder let alone expert, so I could be missing something obvious.

I did see the open-source FXT1 compression. I've been reading, and there is a definite quality degradation when using it. Also, I haven't been able to confirm that the XVR cards support it, and WWJ would still possibly need modified to support it.

[worldwindnewbie]

Hi smcnaughton,

I've been trying to get wwj or any jogl app to work on our solaris boxes, so far I've tried it on sparc sun blade 150, sun blade 1500. And neither of them worked, both gave me a "javax.media.opengl.GLException: glXGetConfig failed: error code GLX_NO_EXTENSION" error. Have you seen this error before? Do you think i am missing something on these solaris boxes or they are just too old? I haven't had any experience playing with openGL, do the solaris machines require some kind of a library such as GLX installed?

[wobster]

I can answer only a couple of these. I've tested WWJ on Solaris/x86 10 with NVidia graphics hardware and the new drivers from NVidia for Solaris/x86 and it runs well. To be honest I doubt that it will run on Solaris/SPARC as the graphics hardware on that platform is a couple of generations old and I think WWJ relies on some fairly recent OpenGL extensions. I've found that WWJ works well on all of NVidia, ATI and Intel graphics chips.

tag, pmurris and others can comment on interoperability with other JOGL code, but in general, as long as you can run the other JOGL component with the latest version of the JOGL library, then everything should work fine.

WWJ runs great on Java 6.

There are enough issues with JOGL's lightweight GLJPanel (mea culpa) that the strong recommendation is to only use WWJ as a heavyweight component. This does mean that WWJ won't currently play well with JInternalFrames, but that's about the only situation where it can't be made to interoperate well with Swing components.
Ken (et al),

Is the GLJPanel ready for prime time on Linux now? I was experimenting with WW running in a Swing desktop application and noticed that it ran pretty well on Windows using GLJPanel, but not on Linux. (The Java application spikes to 95% of the CPU and X at 2% when I attempt to rotate the globe for instance.) I upgraded to the latest NVidia drivers for the gfx-6800 graphics card, but that didn't help. I also tried the -Dsun.java2d.opengl.fbobject=false and -Dsun.java2d.opengl=True. (I also verified that the OpenGL pipeline was enabled.)

I wanted to use the GLJPanel since the heavy weight canvas obscured pull down menus from the menu bar and of course any other swing components that would be overlayed on top of the canvas.

(BTW, both the Windows and Linux version were running on the exact same hardware since I tested it on a dual boot laptop.)

Thanks!

Rob

p.s. I did a kill -QUIT on the running process to get this snippet of stack trace:

"AWT-EventQueue-0" prio=10 tid=0x09d54400 nid=0x1be8 in Object.wait() [0xb335b000..0xb335c130]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at sun.java2d.opengl.OGLRenderQueue$QueueFl usher.flushNow(OGLRenderQueue.java:149)
- locked <0x648f9a20> (a sun.java2d.opengl.OGLRenderQueue$QueueFl usher)
at sun.java2d.opengl.OGLRenderQueue$QueueFl usher.flushAndInvokeNow(OGLRenderQueue.j ava:162)
- locked <0x648f9a20> (a sun.java2d.opengl.OGLRenderQueue$QueueFl usher)
at sun.java2d.opengl.OGLRenderQueue.flushAn dInvokeNow(OGLRenderQueue.java:107)
at sun.java2d.opengl.OGLUtilities.invokeWit hOGLContextCurrent(OGLUtilities.java:95)
at sun.reflect.GeneratedMethodAccessor8.inv oke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.jav a:25)
at java.lang.reflect.Method.invoke(Method.j ava:597)
at com.sun.opengl.impl.Java2D.invokeWithOGL ContextCurrent(Java2D.java:291)
at javax.media.opengl.GLJPanel.paintCompone nt(GLJPanel.java:534)
at javax.swing.JComponent.paint(JComponent. java:1027)
at javax.swing.JComponent.paintToOffscreen( JComponent.java:5122)
at javax.swing.BufferStrategyPaintManager.p aint(BufferStrategyPaintManager.java:277 )
at javax.swing.RepaintManager.paint(Repaint Manager.java:1217)
at javax.swing.JComponent._paintImmediately (JComponent.java:5070)
at javax.swing.JComponent.paintImmediately( JComponent.java:4880)
at javax.swing.RepaintManager.paintDirtyReg ions(RepaintManager.java:803)
at javax.swing.RepaintManager.paintDirtyReg ions(RepaintManager.java:714)
at javax.swing.RepaintManager.seqPaintDirty Regions(RepaintManager.java:694)
at javax.swing.SystemEventQueueUtilities$Co mponentWorkRequest.run(SystemEventQueueU tilities.java:128)
at java.awt.event.InvocationEvent.dispatch( InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQ ueue.java:597)
at java.awt.EventDispatchThread.pumpOneEven tForFilters(EventDispatchThread.java:269 )
at java.awt.EventDispatchThread.pumpEventsF orFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsF orHierarchy(EventDispatchThread.java:174 )
at java.awt.EventDispatchThread.pumpEvents( EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents( EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDi spatchThread.java:122)

"AWT-Shutdown" prio=10 tid=0x09d52c00 nid=0x1be7 in Object.wait() [0xb33ac000..0xb33ad0b0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x648f9978> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at sun.awt.AWTAutoShutdown.run(AWTAutoShutd own.java:259)
- locked <0x648f9978> (a java.lang.Object)
at java.lang.Thread.run(Thread.java:619)

"AWT-XAWT" daemon prio=10 tid=0x09d4f400 nid=0x1be6 waiting on condition [0xb33fd000..0xb33fe030]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x648cb198> (a java.util.concurrent.locks.ReentrantLock $NonfairSync)
at java.util.concurrent.locks.LockSupport.p ark(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueue dSynchronizer.parkAndCheckInterrupt(Abst ractQueuedSynchronizer.java:747)
at java.util.concurrent.locks.AbstractQueue dSynchronizer.acquireQueued(AbstractQueu edSynchronizer.java:778)
at java.util.concurrent.locks.AbstractQueue dSynchronizer.acquire(AbstractQueuedSync hronizer.java:1114)
at java.util.concurrent.locks.ReentrantLock $NonfairSync.lock(ReentrantLock.java:186 )
at java.util.concurrent.locks.ReentrantLock .lock(ReentrantLock.java:262)
at sun.awt.SunToolkit.awtLock(SunToolkit.ja va:241)
at sun.awt.X11.XToolkit.waitForEvents(Nativ e Method)
at sun.awt.X11.XToolkit.run(XToolkit.java:5 48)
at sun.awt.X11.XToolkit.run(XToolkit.java:5 23)
at java.lang.Thread.run(Thread.java:619)

"Java2D Queue Flusher" daemon prio=10 tid=0x09b79c00 nid=0x1be5 runnable [0xb40a9000..0xb40a9fb0]
java.lang.Thread.State: RUNNABLE
at com.sun.opengl.impl.GLImpl.glDrawElement s0(Native Method)
at com.sun.opengl.impl.GLImpl.glDrawElement s(GLImpl.java:3862)
at gov.nasa.worldwind.globes.RectangularTes sellator.render(RectangularTessellator.j ava:499)
at gov.nasa.worldwind.globes.RectangularTes sellator.renderMultiTexture(RectangularT essellator.java:461)
at gov.nasa.worldwind.globes.RectangularTes sellator.access$000(RectangularTessellat or.java:28)
at gov.nasa.worldwind.globes.RectangularTes sellator$RectTile.renderMultiTexture(Rec tangularTessellator.java:93)
at gov.nasa.worldwind.render.SurfaceTileRen derer.renderTiles(SurfaceTileRenderer.ja va:224)
at gov.nasa.worldwind.render.SurfaceTileRen derer.renderTile(SurfaceTileRenderer.jav a:69)
at gov.nasa.worldwind.render.SurfaceImage.r ender(SurfaceImage.java:441)
at gov.nasa.worldwind.layers.RenderableLaye r.doRender(RenderableLayer.java:296)
at gov.nasa.worldwind.layers.AbstractLayer. render(AbstractLayer.java:190)
at gov.nasa.worldwind.AbstractSceneControll er.draw(AbstractSceneController.java:473 )
at gov.nasa.worldwind.BasicSceneController. doRepaint(BasicSceneController.java:27)
at gov.nasa.worldwind.AbstractSceneControll er.repaint(AbstractSceneController.java: 201)
at gov.nasa.worldwind.WorldWindowGLAutoDraw able.doDisplay(WorldWindowGLAutoDrawable .java:227)
at gov.nasa.worldwind.WorldWindowGLAutoDraw able.display(WorldWindowGLAutoDrawable.j ava:171)
at com.sun.opengl.impl.GLDrawableHelper.dis play(GLDrawableHelper.java:78)
at javax.media.opengl.GLJPanel$Updater.disp lay(GLJPanel.java:1056)
at javax.media.opengl.GLJPanel$DisplayActio n.run(GLJPanel.java:1213)
at com.sun.opengl.impl.GLDrawableHelper.inv okeGL(GLDrawableHelper.java:194)
at javax.media.opengl.GLJPanel$2.run(GLJPan el.java:650)
at sun.java2d.opengl.OGLRenderQueue$QueueFl usher.run(OGLRenderQueue.java:202)
- locked <0x648f9a20> (a sun.java2d.opengl.OGLRenderQueue$QueueFl usher)

[marjancek]

"javax.media.opengl.GLException: glXGetConfig failed: error code GLX_NO_EXTENSION" error.You don't have some OpenGL functions available becase probably neither the hardware nor the drivers for it support it.
You could try a software dirver such as MESA, but I have no experience with it. Or buy another video card, of course.

[Ken Russell]

Is the GLJPanel ready for prime time on Linux now? I was experimenting with WW running in a Swing desktop application and noticed that it ran pretty well on Windows using GLJPanel, but not on Linux. (The Java application spikes to 95% of the CPU and X at 2% when I attempt to rotate the globe for instance.) I upgraded to the latest NVidia drivers for the gfx-6800 graphics card, but that didn't help. I also tried the -Dsun.java2d.opengl.fbobject=false and -Dsun.java2d.opengl=True. (I also verified that the OpenGL pipeline was enabled.)


Unfortunately I still can't recommend using the GLJPanel -- the Java 2D / JOGL bridge hasn't received any attention recently, so at minimum you're going to be faced with relatively low performance on most hardware. (I've noticed that very recent Intel hardware seems to have such high bus speeds that the GLJPanel runs very quickly in the default mode).

There are ways to make your menus overlay the heavyweight GLCanvas as described in the JOGL Users' Guide. However Swing components overlaying the GLCanvas will still be a problem.

FYI, my group's ongoing work involves better integration of GUI elements with JOGL based applications, so we hope that we will be able to improve the situation in the future.

[wobster]

Unfortunately I still can't recommend using the GLJPanel -- the Java 2D / JOGL bridge hasn't received any attention recently, so at minimum you're going to be faced with relatively low performance on most hardware. (I've noticed that very recent Intel hardware seems to have such high bus speeds that the GLJPanel runs very quickly in the default mode).

There are ways to make your menus overlay the heavyweight GLCanvas as described in the JOGL Users' Guide. However Swing components overlaying the GLCanvas will still be a problem.

FYI, my group's ongoing work involves better integration of GUI elements with JOGL based applications, so we hope that we will be able to improve the situation in the future.

Thanks Ken for the response. I was able to get the pulldown menus working correctly now for the heavy weight canvas. I think using heavy weight windows/frames when doing popup panels and such should take care of most of the issues. I imagine overlayed lightweight panels (like semi-transparent "drawer" panels) would be a problem, but I've read that people have had some success calling native code to draw those types of panels using JNA. (And of course, the semi-transparency of the panel is mostly eye candy anyway.)

Rob

[Chiss]

Runtime 1.6.0_12 claim to have partially solved the issue of mixing lightweight and heavyweight, and apparently we're not supposed to have anything special to do to make it work.

I'm building an app using the NetBeans platform and I quickly tried it but didn't see any difference (the windows/sliding panes still get painted behind my GLCanvas).

Anybody else having a better luck?

[latelounge]

There is a new article from SUN (September 2009) about mixing light/heavyweight components.
If i understood it right, the central claim is:
"Use the right JRE and it just works".

(As of the JDK 6 Update 12 and JDK 7 build 19 releases, it is now possible to seamlessly mix heavyweight and lightweight components within the same container.)

http://java.sun.com/developer/technicalArticles/GUI/mixing_components/index.html

So we could simply keep GLCanvas without heavy/lightweight issues ?
(I haven't tried mixing for now.)

(three hours or so later...)
Ahhh, well - it was one of these cold November nights... and finally i could not resist trying it myself.
As you will see, i just soldered together a as simple as possible demo - just a mix of GLCanvas and Swing components.
Using JRE 1.5.09, the GLCanvas overlaps the menu-items.
JRE 1.6.16 displays the correct behaviour.

[patmurris]

Good news. Can anyone confirm this is indeed working on Mac and linux machines?

[latelounge]

I got it also working under Ubuntu 9.04
:)

Java version is:
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu11)
OpenJDK Server VM (build 14.0-b08, mixed mode)

And GeForce Go 7300 with NVIDIA driver 180.44

[BrunoSpy]

Good news. Can anyone confirm this is indeed working on Mac and linux machines?

Confirmed ! Great news !

Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Linux 2.6.31.5-server-1mnb
Mandriva 2010.0