Swing/JOGL integration demos

OpenGL Development JOGL Development
#1

Hi folks,

I have been playing recently with the new JOGL feature that allows to mix Swing and OpenGL without any artifact. Despite a few minor problems, I’m glad to say it works really well. I got two demos for you.

The first one shows one of the gears from the famous Gears demo used as an icon in a JButton. Whenever the mouse enters the button, the gear starts rotating. Besides the screenshot below, you can take a look at a video (http://jext.free.fr/button3d.mov) and at the source code (http://jext.free.fr/3DButton.zip). The source code is more a proof of concept than a real solution. I basically set a blank text on the JButton, change its layout to FlowLayout and add a GLJPanel and a JLabel into the button. As a drawback, the focus is not painted correctly. I have a few ideas for better implementations though.

http://jext.free.fr/button1.png

The second demo is the opposite. Instead of putting an OpenGL scene into a JButton, it shows JButtons inside an OpenGL scene (+ extra Java2D stuff). I haven’t released the source code yet because I’d like to disclose it at JavaPolis in two weeks. I will post the source code the 15th or the 16th of December. I have uploaded a video of the demo in different formats: QuickTime 7 (http://jext.free.fr/twinkle.mov), XviD (http://jext.free.fr/twinkle.avi) and DivX 6 (http://jext.free.fr/twinkle.divx). The text and the pictures strip are drawn with Java2D and the buttons at the bottom left are JButton in a JPanel (the rounded rectangle).


http://jext.free.fr/twinkle_small.png

While developing those demos I have stumbled into two important issues. First, using full scene antialiasing doesn’t work (but Ken told me he’d be working on that :). Instead I am using the old ugly accum buffer trick but the major drawback is you lose the possible transparency of the GLJPanel. The second issue is related to Java2D antialiasing. The text and the rounded rectangle in the second demo are painted into offscreen BufferedImages. Painting them directly onto the screen procudes visual artifacts. Chris Campbell and I actually discovered that it happens with text if the font size is greater than 16 (if it is you’ll see each character replaced by the last character of the string). So beware :slight_smile:

#2

Neat little demo you got there.

Wrt Java2D fonts, I wonder if there is going to be a way to grab the Java2D GL pipeline glyph cache and use it, instead of having to write into the buffered image, and pretty much recreate what Java2D GL pipeline already does quite well. Someone once requested this capability on a Java2D forum (IIRC), but aparently at the time no such capability was exposed.

In any event, good going for Swing with all these new developments, people are gonna go crazy with all this new stuff to do.

#3

that looks very cool!
say, have you released the sources for the second demo yet?

does it require mustang? or is it also possible to integrate swing elements into jogl with java 5?

#4

The sources for Romain’s Twinkle demo are linked from here. It does require Mustang; while JOGL’s GLJPanel supports both Java 1.4.2 and 5.0, it isn’t fast with releases before Mustang (and on that release not unless you specify -Dsun.java2d.opengl=true on the command line). Note that you can specify this in Java Web Start JNLP files, which is cool and important for being able to publish such demos easily.

#5

Romain’s webstartable demo runs horribly for me. There is no smooth animation at all, the UI updates in a choppy inconsistent way. It’s less than 1 frame per second.
I’m running Mustang b90 on Win XP SP2 with a nVidia GForce FX 5200 using (ForceWare) driver ver. 84.21

It’s horribly broken. I’m concerned about the reputation Java with JOGL and the OpenGL pipeline will get if this is a common occurance. Considering this is one of the main applications promoting this technology it’s sort of a major bummer.

The Java Console shows a couple exceptions:
Java Web Start 1.6.0-rc
Using JRE version 1.6.0-rc Java HotSpot™ Client VM
…

exception in QueueFlusher:
java.lang.NullPointerException
at org.progx.jogl.rendering.ReflectedQuad.render(ReflectedQuad.java:37)
at org.progx.twinkle.ui.PictureViewer.setAndRender(PictureViewer.java:606)
at org.progx.twinkle.ui.PictureViewer.renderItems(PictureViewer.java:586)
at org.progx.twinkle.ui.PictureViewer.access$22(PictureViewer.java:584)
at org.progx.twinkle.ui.PictureViewer$2.render(PictureViewer.java:534)
at org.progx.jogl.GLUtilities.renderAntiAliased(GLUtilities.java:89)
at org.progx.twinkle.ui.PictureViewer.render3DScene(PictureViewer.java:542)
at org.progx.jogl.CompositeGLPanel.display(CompositeGLPanel.java:73)
at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:77)
at javax.media.opengl.GLJPanel$Updater.display(GLJPanel.java:708)
at javax.media.opengl.GLJPanel$DisplayAction.run(GLJPanel.java:863)
at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:128)
at javax.media.opengl.GLJPanel$1.run(GLJPanel.java:349)
at sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run(Unknown Source)
(same exception repeated once more)

I had a different system at work that did the same thing, but that was many months ago when the demo first came out. The one I just tried is just as bad.

If you look at the comments on Romain’s page the last one, dated March 02, 2006 describes the exact same issue, though he used Mustang b59.

#6

Maybe it is the 5200. This demo still doesn’t work for me. 5200 with the 91.31 drivers on mustang b77.

#7

Runs very smooth here, on a 7800GT (84.26), Mustang b90, on Windows XP 64-bit ed.

I haven’t looked at the demo sources, but maybe he’s doing something fancy that gets emulated on the 5200?

#8

If you download and run the sources take out the specification of -Dtwinkle.aa=true on the command line. I empirically found out that that was causing problems on certain hardware, my own included (Quadro FX Go700 mobile chip). I also found that the new FBO backend for the Java2D/OpenGL pipeline (-Dsun.java2d.opengl=true -Dsun.java2d.opengl.fbobject=true) similarly sped up the demo, so it must be that it in particular stresses some driver feature not hardware accelerated with pbuffers on certain cards.

It’s possible the Aerith demo may be more robust than Twinkle.