SWT/OpenGL Bindings v0.7.0 released - now with lightweight Draw2D support

Continuing on our march towards real JOGL support in SWT, we have another release of the SWT OpenGL bindings to the JSR 231 APIs. These are specifically coded to allow you to use JOGL on any SWT performance in almost an identical way to you would use them on an AWT platform. Specifically, we have completely rewritten large parts of the JOGL RI code to remove anything that even remotely tickles the AWT event thread, thus avoiding the lockup problems on OSX that you get using the RI.

In this release, we have fixed all the timing problems that we found in the last on on X11 platforms. In addition, a major new addition is the ability to use a lightweight Draw2D surface now with JOGL. That’s right, you can have real 3D graphics in the middle of your GEF panel and have it play nicely with everyone, including proper resizing, compositing and alpha support. If you want to get really funky, you could also pull in Aviatrix3D and have a real scene graph there too (Xj3D won’t be too far behind either once we get rid of the AWT image loading that also causes lock ups on a Mac).

Have a look at the new downloads here: http://opengl.j3d.org/swt/download.html

We are currently missing 32bit linux support due to the death of our 32 bit machine, but do have 64bit support for Linux, Solaris/Sparc, OSX universal binaries and Win32. We hope to have the 32 bit linux support available within the next couple of weeks once the repaired machine is back in our hands.

As a SWT/OpenGL programmer, this sounds interesting. I’m curious though as to whether it will provide me any benefits.

My current situation w/ SWT & JOGL, is that I use SWT for all of my GUIs, but when time comes to include some OpenGL, I have the SWT GLCanvas, and use JOGL only for it’s GL interface, and GLU & GLContext classes (I don’t use any of JOGLs canvases, drawables, event listeners, or anything in the com.sun.opengl.* packages). For the rendering loop, I use SWT’s display.asyncExec(Runnable) method on the user interface thread with a current OpenGL context.

I do like the goals of your SWTOpenGL project to remove the little AWT-under-the-hood stuff for those not using AWT, but I’m just wondering if I’ve already removed myself from them by restricting myself to a select few of JOGL’s items? Regardless of your answer, I’ll be giving this thing a try with my project :slight_smile:

Simple answer to why you woiuld want to use our code: Try running your JOGL RI code on a Mac. You’ll see it lock solid within about 2 seconds. The JOGL RI does a lot of very nasty things with the AWT event loop, which then causes the locks on OSX. It does a lot of them in very unobvious places. The problem is that most if the code somewhere touches the Threading or GLContextShareSet classes either directly or indirectly. Inside those classes there are a heap of references to the Java2D class which then does things like look at the AWTEventQueue or make static references to it. As soon as any of those classes are touched, that’s when the OSX version locks solid. Works mostly fine on other platforms, but can’t ever work on OSX whilst any of that class code is in there (and it won’t be due to all the Java 6 OpenGL integration work).

If you want portable code under SWT, don’t use the RI.

I have a very strange problem when I render with JOGL on a SWT Shell both for the JOGL RI and your JOGL SWT lib (that I also posted on the swt newsgroup but without reply). When I try to use FBOs with SWT I’m getting a black screen on windows as soons as I bind the fbo and an occasional flickering on linux (both with current nvidia drivers). Using the same FBO code for rendering works fine with AWT. If I don’t use FBO all rendering works perfectly for both AWT and SWT.
Do you have any idea what could cause that? (Something like special caps for FBO or so?)

Yours,
Stefan

We haven’t done any direct playing with FBOs yet so I don’t have any direct tests to play with. It could well be a timing issue somewhere with the SWT event model. If you could send me a test case and a bit of info about your hardware and OS I can look into it.

Tried the SWT/OpenGL thing by swapping out the JOGL files for those in the SWT/OpenGL. 0.7 download. Compiles and runs fine on a Windows machine. Is there anything else I need to do to properly utilize it?

Yes. There is a system property that must be set first to make the sure GLDrawableFactory pulls our factory implementation. If you have a look in the examples, you’ll see the name of the property that needs to be set. In our code, we’ve kept what we can of the RI, which means it will still work with the AWT panels. However, a lot of the functionality is reduced or removed - such as the Java 6 OpenGL integration work.

OK, added -Dopengl.factory.class.name=org.j3d.opengl.swt.SWTRIDrawableFactory to the VM args. Seems to work fine, although I wish I had a Mac machine so I could make the comparison between this and the JOGL RI to see the locking problem first-hand.

Nice to know that this option is available to Mac users for SWT/OpenGL programs.