JOGL-specific GUI effort

I am going to attempt to make a better-performance AWT+Swing GUI layer for jME which will have the significant constraints of supporting only JOGL and Java 6 (and later).  The pay-offs that justify these constraints are:

  • Robust support for AWT and Swing according to J2SE API.  I.e., supports AWT and Swing like JMEDesktop, but without all of the bugs, esp. wrt modality and input.

  • No need to learn new container and widget APIs, as is now needed for Fenggui and GBUI.  Code accorrding to J2SE AWT and Swing APIs.

  • Best performance possible from an OpenGL desktop system, due to JOGL+Java6's new support of Java2D OpenGL pipeline.

  • Great performance from windowed (i.e., not fullscreen) mode.  (Once again due to the pipeline enhancement).

Due to the constraints (listed int he first sentence of this post), this is not intended to be a replacement for JMEDesktop, Fenggui, or GBUI, but an alternative where the constraints are acceptable.  For the same reasons, I don't expect it to ever be assimilated into the main jME code base.  LWJGL has added support for AWT and Swing, but I don't think the integration effort to support LWJGL with this would be worth the effort, due to performance limitations and constraints which JOGL does not have.

If there is any reason why I should not be able to integrate jME and JOGL in this way, please save me some time and explain.  I expect this will take many hours of work, and I'd rather not waste my time if there is any impediment that I won't be able to overcome.

This strategy also assumes that jME's JOGL support is strong enough that most jME features will work.  I usually work with LWJGL because back when I started with jME most things I tried would not work with JOGL, and the jME API still has several LWJGL-specific classes with no apparent JOGL counterpart.  I'll be testing this, but it would be great if somebody could save me time here too by reporting their recent experience or knowledge of jME 2.0 trunk's limitations of feature support with JOGL.

Testing on my dev platform completed (Linux).

The bad news is, with the Java2D pipeline enabled, my jME tests didn't work reliably.  Since tests with the same exact setup but without jME work fine, it's likely that these issues could be resolved by fixing initialization sequences and such.  The carrot for such work is that when it is working I am getting FPS from 250 to 750 with 3D scene + desktop active.  (The first benchmarks that I reported for pipeline in my earlier post were completely wrong because I mis-transcribed the property name needed to enable it :frowning: ).

I therefore changed my immediate goal, to determine if performance for basic JOGL with Windowed mode Swing, without the Java2D pipeline. is acceptable.  If yes, then I can take my time working on the jME issues with the pipeline.

Windowed (non-fullscreen) Swing with and without JDesktopPane working flawlessly WITHOUT PIPELINE at 55-60 FPS and 63-70 FPS correspondingly, loaded up with desktop widgets and a textured, animated high-res model.

Here are some of the things that I tested:

Focus traversal

Pulldown menus

Popup menus

Modal windows (JOptionPane and JFileChoosers)



jME scenes (nested objects, mats, textures, manipulating with input, animation)

OS desktop manager interaction (resizing frame, closing)

listeners for key and mouse events

For people who have used JMEDesktop, the JDesktopPane variant behaves exactly as you would want JMEDesktop to behave.

Now I am going to test with various out platforms.

UPDATE:  Behavior is extremely reliably on the many Windows variants that I and my helpers tested.  Performance could be better.  If I can get the Java2D pipeline fixed, this will be a killer combo.

AWT seems to work fine on my computer as long as it doesn't directly mix with OpenGL for inputs on the LWJGL side.  I think JOGL tends to behave better overall, but it still gives a problem or two with AWT in its mix.  I assume AWT might perform better for cell phones or Windows, but I've never targeted cell phones for software.  I use the 190.x nVidia drivers in Ubuntu Linux.  I don't mean to discourage you since I focus more on LWJGL at the moment.

Phase 1 completed:  Testing JOGL w/ Swing without jME.  Getting 90 FPS with game world objects + MDI (JDesktopPane with pulldown menus, JInternalFrames, and JToolBar present).  Just as importantly, for everything I've tried so far, focus and input behave exactly as without JOGL (nothing like JMEDesktop).

This is without pipeline.  I haven’t yet got pipelining to work with texture-combine-functions, so am getting everything working without pipelining first.  Without pipelining, I haven’t run into a single item, incl. input system and JDesktopPane, which behave differently than J2SE Swing.

Requires Java 6.  Try keys “p”, “i”, “o”, “O”, “r”, “R” and different settings on the Settings screen (in the File pulldown).

Note that I’ve implemented camera movement control differently than the jME input handlers.  Arrow keys and w,a,s,d,q,z are for direct relative linear movement, and mouse click-and-drag is for changing the forward direction.  LMB+RMB work as in some RPGs to move forward while controlling direction with mouse movement.  Mouse scroll wheel also works.

Reports of your platform and frame rate achieved (reported to javaws console with “t”) would be appreciated.


It works fine under Vista 64 bits.

gouessej said:


It works fine under Vista 64 bits.

Thanks very much, gouessej.

I got your specs from another discussion, but could you tell me, for comparison purposes, what frame rate you normally get with jME or other 3D programs on that PC, if you know?

nice work!

blaine said:

I got your specs from another discussion, but could you tell me, for comparison purposes, what frame rate you normally get with jME or other 3D programs on that PC, if you know?

slightly OT: this gives me a thought... should there be a kind of intensive polygon/lighting test of sorts so we have a 'native' benchmark to compare against when questions like this come up?