New tutorial on AWT/SWT/Swing/GLJPanel/GLCanvas

Hi guys!

I wrote a new page at http://jogamp.org/wiki/index.php/Using_JOGL_in_AWT_SWT_and_Swing that shows how to use JOGL in all five ways that I know of:

- AWT
- SWT
- SWT with SWT-AWT bridge
- Swing with AWT GLCanvas
- Swing with GLJPanel

I ported a simple example program to work all five ways, with the common parts factored out so you can see the differences between the window toolkits more clearly. There's also a bit of advice on which one to choose in what situation, though I've left out some complications like how to do Julien's optimization of the SWT-AWT bridge.

Let me know if you see any problems!

-w

Hi

Thank you for this nice wiki page.

My "complications" are mandatory to use the debug pipeline (which is very useful when developing an OpenGL application) and to work around some known limitations/bugs of the SWT/AWT bridge. Not using them exposes you to threading, layout problems and stack overflow errors on Linux (except if Java is up to date) in more elaborated applications. Therefore, it would have been fine to evoke such problems. There is one missing example: SWT with SWT/AWT bridge + GLJPanel (which works very bad when resizing the SWT component).

In my humble opinion, it would be fine to keep your simplified and very clear example (to allow people to really see the differences between all solutions) and to provide a more robust one with my fixes (these are neither complications nor optimizations).

Maybe you could be a little bit more accurate concerning the limitations of GLCanvas that you can go beyond with GLJPanel (non opaque components, support of JInternalFrame instances, etc...). You speak about performance, it is very important to mention that GLJPanel is quite very "memory expensive" like the GLCanvas with auto swap buffer mode off.

Best regards.

Hi Julien,

If you have time to add your fixes to my SWT-AWT bridge example, I can incorporate that into the wiki page. I'll also add a note that it's mandatory if you want to use the debug pipeline (I haven't tried it myself, so I didn't realize).

Also, could you give me some more detailed examples of how GLJPanel lets you overcome problems with GLCanvas? I've heard that this is the case, but I don't have first-hand information that I can write with confidence.

Hi Wade

I'll try to provide a simple example as soon as possible.

A GLCanvas is not a panel, it extends Canvas. If I want to use a JInternalFrame, you can only add it to its container, the Frame whereas GLJPanel is a container. As a result, a dirty grey area appears under the JInternalFrame when you move it if it is in a Frame and this grey area cannot disappear whereas it works fine with the GLJPanel.

Wade,

thanks for this tutorials! I checked the SWT-AWT bridge in my SWT app and it is quite nicely working, including the multisampling which is broken in native SWT under MS Windows.
The only thing preventing me from immediately switching to it, is its performance :(
Depending on current complexity of the scene, I get:
* SWT: 178fps, SWT-AWT: 142fps
* SWT: 27fps, SWT-AWT: 23fps

Do you know of anything that can be done to improve the bridge's performance?
I am thinking also about fixing the SWT's canvas, but it seems like quite a bit of digging in SWT's code, including the native methods... :-/

Hi Matt,

Could you post your code that shows the multisampling bug in SWT's GLCanvas? I'd like to investigate that further and see if I can fix it. I've been looking for an excuse to build SWT

As for performance of the SWT-AWT bridge, Julien has some techniques for that -- he said above that he might be able to provide a simple example

Wade,

actually it's not even a bug, it's a missing feature that made me LOL when I compared source code for SWT GLCanvas both Linux and Win versions.

Generally, you simply set up multisampling like:

GLData data = new GLData();
data.doubleBuffer = true;
data.depthSize = 24;
data.alphaSize = 8;
data.sampleBuffers = 1; // <------------this
data.samples = 4; // <-------------- this
this.canvas = new GLCanvas(parent, SWT.NONE, data);

you run this under Linux and it works like a charm. Then you run the same code under Windows and no multisampling at all... so you get confused.
You look in the Linux source of GLCanvas and you see in the constructor. There's a glxAttrib array being filled with data from GLData. The very last fields being filled:

if (data.sampleBuffers > 0) {
        glxAttrib [pos++] = GLX.GLX_SAMPLE_BUFFERS;
        glxAttrib [pos++] = data.sampleBuffers;
}
if (data.samples > 0) {
        glxAttrib [pos++] = GLX.GLX_SAMPLES;
        glxAttrib [pos++] = data.samples;
}

so... yup, it's working there.

Now you go to Windows implementation of GLCanvas and its constructor. This time we have PIXELFORMATDESCRIPTOR instead of glxAttrib array. But it gets filled with GLData similarly to Linux version. So you scroll down and see this:

        //FIXME - use wglChoosePixelFormatARB
// if (data.sampleBuffers > 0) {
// wglAttrib [pos++] = WGL.WGL_SAMPLE_BUFFERS_ARB;
// wglAttrib [pos++] = data.sampleBuffers;
// }
// if (data.samples > 0) {
// wglAttrib [pos++] = WGL.WGL_SAMPLES_ARB;
// wglAttrib [pos++] = data.samples;
// }

and there it is... one big LOL. :-/
No wonder SWT's multisampling isn't working under Windows if its whole >>implementation<< is in fact a commented out code copypasted from Linux impl and marked as FIXME. :-)

I guess the developer responisble for this part gave up Windows multisampling when he realized there's gonna be a bit more work do be done. Later in canvas constructor the WGL.ChoosePixelFormat method is used and it does not support multisampling, one has to use wglChoosePixelFormatARB, and check for this ARB existence at first... it's something like this:
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=46

I hope this helps :)

Look at this example in the attachment (and please vote for this bug):
https://jogamp.org/bugzilla/show_bug.cgi?id=455

It allows to get a better framerate but this bug increases a lot the memory consumption (it was working fine with JOGL 1.1.1a). Sven, if you have an idea, let me know.

Here's the Bugzilla entry for that SWT GLCanvas bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=136514

I'll vote it up, and see if I can submit a patch. I'll need to do some learning first, though

Hi Julien,

I've added your example of how the AWT GLCanvas can have integration problems with Swing when using JInternalFrames, and I've also added a mention of the lack of multisampling in the SWT GLCanvas on Windows.

Sorry I should have provided a more simple example like yours. I'm so busy with the JOGL 2.0 renderer of Ardor3D, some other problems with GLJPanel that I don't know how to fix (wrong size or shift of the panel on resize of its container).

I successfully compiled the SWT JAR for Windows 64-bit for the first time this evening. Once I get the native libraries compiling too, I'll take a stab at adding multisampling. How hard can it be?

Do you plan to fix all known bugs of SWT GLCanvas?

This should not be that difficult, granted you are familiar with WGL API :)

But to be honest, I am thinking about switching to JOGL's GLCanvas, as the multisampling is not the only drawback of SWT's canvas... after some recent changes it's external GLContext became incompatible with JOGL GL3 profile, as I mentioned in other thread.
Though it would be nice to get rid of this AWT bridge, but developing NEWT based GLCanvas for SWT might not be that quick and simple... :(

Yeah, it sounds like I need to do a super-simple OpenGL 3+ example across all of our canvases to see where they stand. I haven't used OpenGL later than 2.0 very much yet, because most older computers at work don't support past OGL 2.

If I have any success fixing SWT multisampling, I can start thinking about adding the option to create an OGL 3 canvas -- I don't want to get ahead of myself  We need a better SWT binding anyway, so why not modify the existing one instead of creating one from scratch?

Be patient, I plan to work on a NEWT-based canvas for SWT, I need it too. I work both on very old machines supporting only OpenGL 1.3 and recent machines supporting OpenGL 3. The problem is that I'm not accustomed to write C/C++ code and it might be necessary.

Wade Walker wrote

We need a better SWT binding anyway, so why not modify the existing one instead of creating one from scratch?

Well, mainly to avoid writing own native code for every posible system. :) Using the NEWT-SWT bridge should spare all the native part of the coding, and provide the reliable and maintained solution...
Anyway... any solution that would be as fast as current native SWT canvas and easy to keep up to date with OpenGL stuff, would be great ;)

Actually, implementing my suggestion is not that hard. You need to implement a NEWT SWT canvas based on org.eclipse.widgets.Canvas, a NEWT SWT display based on the Display class of SWT, a NEWT SWT screen based on... I don't know?? and a NEWT SWT window using a Composite instance as a container, a NEWT SWT canvas and a Shell instance as a frame. The problem is that some methods are always called on the event dispatching thread which means that I have to use asyncExec to call SWT methods on the SWT dispatching thread. If someone else feels more comfortable than me to implement these classes, let us know.

gouessej wrote

... You need to implement ... a NEWT SWT display based on the Display class of SWT, ... and a Shell instance as a frame.

Would this work for cases like Eclipse RCP apps where the framework creates the Display and Shell for you? In that case you wouldn't be able to create a new NEWT-based Display and Shell. I'm not sure how to handle that situation other than:

- Use SWT_AWT bridge (could be faster, but at least it works right now)
- Use SWT GLCanvas (fast, but only if you're restricting yourself to <= OGL 2.0 and don't need multisampling)
- Somehow wrap a NEWT window inside an SWT Canvas (but no NEWT on Mac yet?)
- Fix SWT's GLCanvas (difficult and thankless task?)

I don't think I understand these issues well enough yet... I need to dig into the code some more.

In Eclipse RCP, you could use the already available display, it is not a problem, the JOGL NEWT SWT display could wrap this SWT display instead of creating a new one. I prefer using an SWT NEWT window as a Composite if possible.