Looking for example using SWT GLCanvas

Greetings,

Thanks for the good work you all are doing on JOGL.  I'm about to port a large engineering graphics application to Eclipse RCP (Indigo).  Right now I'm exploring the best windowing toolkit to tie our OpenGL/JOGL code to our Eclipse RCP/SWT views.  I'm developing on Windows XP(32bit) with Java 1.7SE update 2 and  JOGL v2.0-rc9.

I've read the tutorials and JavaDocs for Eclipse RCP/SWT/JOGL and have managed to produce evaluation tests for #1 and #2 of the four options Julien posted here.

1) [WORKS] the obsolete org.eclipse.swt.opengl.GLCanvas (thanks to Wade's excellent wiki article)

                org.eclipse.swt.widgets.Composite parent;

                // canvas
                javax.media.opengl.GLProfile glprofile = GLProfile.getDefault();
                org.eclipse.swt.opengl.GLData gldata = new GLData();
                import org.eclipse.swt.opengl.glCanvas = new org.eclipse.swt.opengl.GLCanvas(parent,
                                                                                                              SWT.NO_BACKGROUND, gldata);
                // OpenGL context
                javax.media.opengl.GLContext glContext = GLDrawableFactory.getFactory(glprofile).
                                                                                                createExternalGLContext();

2) [WORKS]  javax.media.opengl.awt.GLCanvas via org.eclipse.swt.awt.SWT_AWT (from the same article)

                org.eclipse.swt.widgets.Composite parent;

                // canvas
                javax.media.opengl.awt.GLCanvas glCanvas = new GLCanvas();

                // bridge
                final org.eclipse.swt.Composite composite = new Composite(parent, SWT.EMBEDDED|SWT.NO_BACKGROUND);
                java.awt.Frame frame = SWT_AWT.new_Frame(composite);
                frame.add(glCanvas);

3) [WORKS]  com.jogamp.newt.opengl.GLWindow via com.jogamp.newt.awt.NewtCanvasAWT via org.eclipse.swt.awt.SWT_AWT

                org.eclipse.swt.widgets.Composite parent;

                // window
                javax.media.opengl.GLProfile glprofile = GLProfile.getDefault();
                javax.media.opengl.GLCapabilities caps = new GLCapabilities(glprofile);
                com.jogamp.newt.opengl.glWindow = GLWindow.create(caps);

                // canvas
                com.jogamp.newt.awt.NewtCanvasAWT canvas = new NewtCanvasAWT(glWindow);

                // bridge
                final org.eclipse.swt.Composite composite = new Composite(parent, SWT.EMBEDDED|SWT.NO_BACKGROUND);
                java.awt.Frame frame = SWT_AWT.new_Frame(composite);
                frame.add(canvas);

Seems doable but seems a bit convoluted... is this really a practical option?  Does it provide any unique advantage over the others?

4) [EXCEPTION] com.jogamp.opengl.swt.GLCanvas

I modified #1 to use the new SWT GLCanvas but cannot get #4 to run.  I get a java.lang.ClassNotFoundException: org.eclipse.swt.widgets.Canvas thrown from the constructor of  com.jogamp.opengl.swt.GLCanvas.  (It compiles fine.)

Does anyone have a few lines of example code that demonstrate how to use the SWT GLCanvas?  Wade mentioned that he might try this last April.  Could you post a sample?

I see that there is an "in progress" feature request for a native SWT binding.  Do I need to wait for that or can I use rc9 with some amount of cleverness?

Regards,
Dan

Maybe this could help you.

     http://forum.jogamp.org/Switched-to-JDK-1-7-GLCanvas-buggy-on-mac-td4025496.html#a4025501

     https://sites.google.com/site/justinscsstuff/jogl-tutorial-2

Hi

I avoid using #1 because it would cause so much troubles especially under Linux. I used #2 at work (in an Eclipse RCP application too) but with some tricks not mentioned in Wade's tutorial (to avoid crashes when using the debug pipeline). My colleague uses #3 successfully, NEWT is a bit faster and more reliable that AWT. I don't understand why you get such an exception, it is very strange. In my humble opinion, it does not come from your code but something might be wrong in your environment. org.eclipse.swt.opengl.GLCanvas extends org.eclipse.swt.widgets.Canvas too, I don't know why it works but not com.jogamp.opengl.swt.GLCanvas.

Hunting down the ClassNotFoundException: org.eclipse.swt.widgets.Canvas has been somewhat difficult.  Though I have 25 yrs experience in C/C++ development I'm new to Java just this year.  Maybe someone can enlighten me in the "Java Way."

It seems that my application cannot even load the jogamp SWT GLCanvas like this:

Class<?> t = Class.forName("com.jogamp.opengl.swt.GLCanvas");

It gets a run-time exception even though it compiles fine.

I've tried the latest build of JOGL (b784) and Glugen (b575) , updated my JDK to 1.7u5 have the latest SWT library (3.7.2) for Eclipse Indigo.  It seems that the super call in GLCanvas just cannot resolve the org.eclipse.swt.widgets.Canvas in the Eclipse RCP plugin environment?  I've read all about the Buddy Class loading and the Context Class loader, but neither of these seems to apply here.

Next step is to try to build JOGL using Java 1.7 in Eclipse.  Does anyone know if this is possible?

If you're creating a plugin app, you might need to check your RCP project's dependencies: it should contain org.eclipse.ui, which in turn brings in org.eclipse.swt. I've got a tutorial on RCP with JOGL at https://wadeawalker.wordpress.com/2010/10/09/tutorial-a-cross-platform-workbench-program-using-java-opengl-and-eclipse/ which you might find helpful.

Wade,

Hey, it's thanks to your well written tutorial mentioned that I've gotten this far.

The funny thing is that my RCP plugin compiles fine so I know that all dependencies are satisfied at compile time.  The ClassNotFoundException occurs at run-time.  This wiki article helps shed some light on the differences.

I'm new to Java so the best I can figure out is that ClassLoader cannot find the super class (org.eclipse.swt.widgets.Canvas) of com.jogamp.opengl.swt.GLCanvas when it's constructed.  I'm using a higher version of the JDK (1.7u5) and also SWT (3.7.2) than the rc9 JOGL jars were built with.  Could this be the cause?  I have not been able to rebuild JOGL with my Eclipse yet to test this theory.

The only other idea I have is the bundle specific classloaders as described in this Eclipse Corner article are not working properly.

Dan

OK, I just realized I had been misreading your posts -- I hadn't noticed that this error was from within the JOGL SWT canvas, not the original SWT canvas :)

I haven't tried using the new JOGL SWT canvas yet, partially because it mixes AWT-style GLAutoDrawable with SWT (I'd like to keep my SWT apps "pure" SWT), and partially because my apps don't yet need multisampling, which the new canvas enables.

You are right that RCP apps use custom classloaders during startup, but the SWT JAR should already be on that classpath (assuming you've set it up the same as in my tutorial). You could always try breakpointing the code right before it crashes and examining the classpath and classloader there (maybe by inserting some custom code)... maybe that would shed some light on what's going on.

drstine wrote

Next step is to try to build JOGL using Java 1.7 in Eclipse.  Does anyone know if this is possible?

Yes, I have done this successfully (both building and using for an RCP app) on Windows, Linux, and OS X. The only gotcha is that Java 1.7 on OS X requires dynamic libraries in Eclipse apps to be suffixed with .dylib, instead of .jnilib, so you might have to rename those files if you're using that platform.

Wade Walker wrote

You are right that RCP apps use custom classloaders during startup, but the SWT JAR should already be on that classpath (assuming you've set it up the same as in my tutorial).

Do the automatic loading and extraction of native libraries need to modify the classpath and/or the library path?

In the case of RCP, it replaces the standard classloader with a new one which tries a series of class load locations and also allows insertion of new locations (as "hooks").  Some of the paths that System.loadLibrary() tries are also determined by this classloader through its findLibrary() method, which is how RCP can use library paths that are not on LD_LIBRARY_PATH.

I assume Sven has done something similar for JOGL's auto extraction and loading.

Hey JOGL Community,

I was away on a C++ project for about four months so haven't been looking at the SWT Canvas problem for a while.  The break must have helped my brain because I figured out the ClassNotFoundException just now.

For reference, I'm using Eclipse Juno (4.2) and JOGL rc11 on Win7/64.  This is an Eclipse RCP project.

Very simply, my com.jogamp.jogl.rc11 plugin has a run-time dependency on org.eclipse.swt that must be set in a MANIFEST.MF Require-Bundle directive (via the wizard).  It's pretty obvious once you see it.

Coming from a fully compiled and linked language such as C++ I find it difficult to track down unresolved dependencies that don't show up at build time.  Now I understand that build-time error messages come from the Java compiler and that Eclipse OSGi will report the run-time "link" errors as it tries to load the plugins (bundles).

So now the NewtCanvasSWT integrates nicely with my RCP view Composite and I've successfully built all five ways to use JOGL with windowing toolkits.

Thanks again for a great library.