JOGL Error in Eclipse on MacOSX

I worked my way through Wade's excellent little tutorial:

 http://wadeawalker.wordpress.com/2010/10/24/tutorial-creating-native-binary-executables-for-multi-platform-java-apps-with-opengl-and-eclipse-rcp/

Which is nice because it avoids the heavyweight SWT_AWT bridge.  However, when I run the tutorial on Mac OSX 10.6, I get an error down in the bowels:

Could not create the view: drawable has invalid handle: com.jogamp.opengl.impl.macosx.cgl.MacOSXExternalCGLContext$Drawable[Realized true,
        Factory   com.jogamp.opengl.impl.macosx.cgl.awt.MacOSXAWTCGLDrawableFactory@1b778d0c,
        handle    0x0,
        Window    NullWindow[config class
etc.

This isn't due to Wade's tutorial code, I reproduced in a simple Eclipse view as well.  Anyone else seen anything like this?

TIA, Ric

Hi

Build JOGL 2.0 beta on Mac OSX from the source and let us know whether you reproduce this bug.

Wade's tutorial is excellent but the SWT OpenGL API including the GLCanvas he used is no more maintained since 2006 and quite buggy. There is no very reliable solution to mix SWT with JOGL, each approach has its limitations. The SWT_AWT bridge is silly, it returns a zero-sized visible AWT frame that has some strange behaviors when containing a canvas (the layout works bad, it is not a real frame but an embedded frame). If you need some help to use it, let me know. I should write a tutorial about this.

The best solution would be an implementation of NEWT for SWT.

Thanks for the reply.  I understand about the ancient characteristics of SWT GLCanvas.  I've been doing this a while myself... :-)  A write up - somewhat out of date now - is here:

http://www.geofx.com/html/OpenGL_Eclipse/OpenGL_Eclipse.html

And while AWT_SWT is perhaps silly, it works for me.  I'd just like to avoid the heavyweight approach of using AWT.  I have heard several people refer to NEWT, but the documentation seems to be practically non-existent, but perhaps I just missed it.  And I cannot find any sign of the NEWT for SWT you mention.  Can you post a pointer to the documentation and/or demo?

TIA, Ric

Ric Wright wrote

Thanks for the reply.  I understand about the ancient characteristics of SWT GLCanvas.  I've been doing this a while myself... :-)  A write up - somewhat out of date now - is here:

http://www.geofx.com/html/OpenGL_Eclipse/OpenGL_Eclipse.html

And while AWT_SWT is perhaps silly, it works for me.  I'd just like to avoid the heavyweight approach of using AWT.  I have heard several people refer to NEWT, but the documentation seems to be practically non-existent, but perhaps I just missed it.  And I cannot find any sign of the NEWT for SWT you mention.  Can you post a pointer to the documentation and/or demo?

Actually your example works in trivial situations but neither in "complicated" GUIs (mix of lots of AWT and SWT components especially on Linux, some of them keep frozen and not fully drawn :s) nor with the TraceGL and DebugGL classes (it crashes almost immediately in the GLDrawableHelper).

Sven suggested me to write this implementation (NEWT for SWT), it does not exist yet.

Well, I guess I would dispute the "trivial" part.  The background for this is that I am writing an Eclipse perspective that allows one to write Java-based modelling, kind of like VTK.  This uses Java reflection to allow users to write a single (or multiple) module that performs some modelling effort and is automagically integrated into GMS.  As you can see from the attached screenshots, this is not a simple app and integrates all sorts of SWT and WST functionality, uses Java reflection extensively and supports a complex JOGL based library that implements a pretty complete implementation of the PostScript APIs. The tempwave animation you see in the screenshot runs easily at 60 FPS on each system I have.  Primary bandwidth problem is the tesselation in GLU since I have to tessellate the PostScript strokes.

I have this running on WinXP 32bit, Win7 64 bit and MacOSX.  I don't have a Linux box these days so I don't know about that.

So I feel that this is pretty non-trivial.  But it is currently based on JOGL 1.1.1.  I thought it would be interesting to look at JOGL2, hence my experiments.  But frankly, JOGL 1.1.1 and the SWT_AWT bridge is working for me, so I'll probably stick with it for now.  My focus is getting GMS done and I don't want to fight the tools.  But I appreciate the awesome jobs you and the rest of the JOGAMP team are doing and am looking forward to the release of JOGL 2.

Cheers, Ric

gms_overview.JPG
gms_datasets.jpg
gms_views.jpg
gms_project_gms.jpg

Ric Wright wrote

Well, I guess I would dispute the "trivial" part.  The background for this is that I am writing an Eclipse perspective that allows one to write Java-based modelling, kind of like VTK.  This uses Java reflection to allow users to write a single (or multiple) module that performs some modelling effort and is automagically integrated into GMS.  As you can see from the attached screenshots, this is not a simple app and integrates all sorts of SWT and WST functionality, uses Java reflection extensively and supports a complex JOGL based library that implements a pretty complete implementation of the PostScript APIs. The tempwave animation you see in the screenshot runs easily at 60 FPS on each system I have.  Primary bandwidth problem is the tesselation in GLU since I have to tessellate the PostScript strokes.

I have this running on WinXP 32bit, Win7 64 bit and MacOSX.  I don't have a Linux box these days so I don't know about that.

So I feel that this is pretty non-trivial.  But it is currently based on JOGL 1.1.1.  I thought it would be interesting to look at JOGL2, hence my experiments.  But frankly, JOGL 1.1.1 and the SWT_AWT bridge is working for me, so I'll probably stick with it for now.  My focus is getting GMS done and I don't want to fight the tools.  But I appreciate the awesome jobs you and the rest of the JOGAMP team are doing and am looking forward to the release of JOGL 2.

Cheers, Ric

gms_overview.JPG
gms_datasets.jpg
gms_views.jpg
gms_project_gms.jpg

Actually the first "problem" I evoked is platform-dependent (it happens only on Linux), you can reproduce it easily by creating an embedded composite and putting even a simple SashForm into it.

The second problem happens only when you enable the debug pipeline very early.

Therefore, they do not bother you if you don't mind of Linux and if you never use the debug pipeline at the launch of your application. However, your tutorial is on the web, some Linux users might have the same problems than me (I'm permanently on Linux), it would be useful to update your tutorial in order to include my unfortunate "findings":
- use the workaround of the bug 6678385 on Linux to avoid some exceptions when creating an AWT frame with SWT_AWT or use the JDK 1.7
- create the GLAutoDrawable instance (GLCanvas or GLJPanel, start the animator, etc...) rather in a ComponentAdapter set on the frame and called once when the frame is resized for the first time (override componentResized(ComponentEvent e))
- call doLayout() on this frame after adding the GLAutoDrawable instance into it

If you prefer, I can write a small tutorial in which I refer to yours and I add these things.

I use VTK too.

Ah, that makes sense.  No, I don't even have a Linux box.  I think it would be better if you wrote a short tutorial demonstrating how to work around the problems.  I am uncomfortable telling people about a solution that I haven't myself tried.

And, as I said, I would be happy to get away from AWT_SWT but it currently is the only really viable solution for me and I want to work on my project, not the tools.  I look forward to the release of JOGL 2.

Thanks, Ric

Ric Wright wrote

Ah, that makes sense.  No, I don't even have a Linux box.  I think it would be better if you wrote a short tutorial demonstrating how to work around the problems.  I am uncomfortable telling people about a solution that I haven't myself tried.

Ok I see what you mean. I will write a small article about these problems with a link to your tutorial as it is very well detailed.

Ric Wright wrote

And, as I said, I would be happy to get away from AWT_SWT but it currently is the only really viable solution for me and I want to work on my project, not the tools.  I look forward to the release of JOGL 2.

I understand your position. I "wasted" a lot of time in repairing JMonkeyEngine 2 instead of using a reliable engine supporting JOGL, you don't want to spend a lot of time on modifying and improving a tool. However, as I have no access to Windows and Mac, I might need some help only for testing.

Sven repaired the autobuild (yeah!!!!) and as usual, he made a great job :)