JOGL with SWT(and NEWT) and OpenGL ES 2.0 for Eclipse RCP

I want to run a interactive app (i.e. user can move 3D models through interaction) in Eclipse RCP.
Thus I need to use SWT.

I found the below tutorial by Wade Walker to be very helpful
http://wadeawalker.wordpress.com/2010/10/09/tutorial-a-cross-platform-workbench-program-using-java-opengl-and-eclipse/

I have two doubts
1.)I am assuming the above tutorial would work with GLES 2.0 as well if I change profile to OpenGL ES 2.0 on desktop right?

2.)Should I use "NEWT" also as mine is a interactive application? Or NEWT is not required? How do we integrate NEWT with SWT (with GLES 2.0 profile) ?

Hi

You have 4 solutions to do that:
- use the obsolete SWT heavyweight OpenGL canvas of SWT/Eclipse
- use SWT/AWT bridge with a GLCanvas
- use SWT/AWT bridge with NewtCanvasAWT + GLWindow (NEWT)
- directly use the official SWT heavyweight OpenGL canvas of JOGL

You have to put your JOGL "canvas" directly or via a bridge into an SWT container (Composite).

As far as I know, you can use any profile, you're not forced to use OpenGL ES 2. The first option is more limited as the OpenGL binding of SWT is no more maintained for years and is buggy. Good luck.

Edit.: Wade's tutorial are very good and I assume he spent quite a lot of time in writing them. If something is missing, maybe we could add some information about these aspects in the wiki.

Hi Seahorse,

I'm glad you found the RCP tutorial helpful  As Julien mentions, my use of the old SWT GLCanvas is a bit obsolete -- if you want to use more advanced OpenGL features like multisampling and shaders, you'd need to change the canvas. For now, I'd suggest the second option Julien mentions ("SWT/AWT bridge with a GLCanvas"), which I demonstrate on the wiki at http://jogamp.org/wiki/index.php/Using_JOGL_in_AWT_SWT_and_Swing.

As far as NEWT goes, it's not necessary to use it, though you could if you wanted to. I haven't had much experience with this option, though. I'm going to try Julien's fourth option ("directly use the official SWT heavyweight OpenGL canvas of JOGL") in April when I've got some time off -- this new canvas is not widely used yet, so it might require me to make a few bug fixes to for it to work in all cases.

I tried to follow all that, but when I try to call GLProfile.initSingleton(), I get a bizzare jar error.  Any idea what this means?

Thanks,
Nick

!SESSION 2012-04-18 01:13:20.914 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.6.0_20
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments:  -product nickburner.product
Command-line arguments:  -product nickburner.product -data /home/nickgeorge/workspace/../runtime-nickburner.product -dev file:/home/nickgeorge/workspace/.metadata/.plugins/org.eclipse.pde.core/nickburner.product/dev.properties -os linux -ws gtk -arch x86_64 -consoleLog

!ENTRY org.eclipse.ui.workbench 4 0 2012-04-18 01:13:22.645
!MESSAGE Unable to create view ID nickburner.view: An unexpected exception was thrown.
!STACK 0
java.lang.IllegalArgumentException: JAR URL doesn't start with 'jar:', got <bundleresource://27.fwk717098535/com/jogamp/common/os/Platform.class>
        at com.jogamp.common.util.JarUtil.getJarSubURL(JarUtil.java:140)
        at com.jogamp.common.os.Platform$3.run(Platform.java:309)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.common.os.Platform.loadGlueGenRTImpl(Platform.java:303)
        at com.jogamp.common.os.Platform.<clinit>(Platform.java:214)
        at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:81)

On 04/18/2012 10:16 AM, Nick George [via jogamp] wrote:
> I tried to follow all that, but when I try to call GLProfile.initSingleton(),
> I get a bizzare jar error.  Any idea what this means?
>

It's already fixed in 'upstream' not RC5 release though.
Now you just get a 'catched' message, but it will continue processing
- here: trying to find the native libraries the old fashion way.

Try this test build:
  http://jogamp.org/deployment/jogamp-test/archive/jogamp-all-platforms.7z

~Sven

Thanks for the quick answer.  That's definitely a step in the right direction!  Now I can get it to run in eclipse, but when I try to build the product, I get odd behavior:  1 in 10 times or so it will work, and the rest of the time, I get an hs_err_pidXXXX log that looks the below.  Looks like a problem with a mutex, is something not releasing properly?

Thanks again,
Nick

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fdc4dc2d3c4, pid=2804, tid=140584180606720
#
# JRE version: 6.0_20-b20
# Java VM: OpenJDK 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea6 1.9.13
# Distribution: Ubuntu 10.04.1 LTS, package 6b20-1.9.13-0ubuntu1~10.04.1
# Problematic frame:
# C  [libpthread.so.0+0x93c4]  pthread_mutex_lock+0x4
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
#   https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

The JVM should also be dumping a stack trace that shows how pthread_mutex_lock is getting invoked -- we'd need to look at that to see what's going on here (for example, whether it's your code doing the locking or JOGL's code).

I used JOGL 2 inside Eclipse RCP all day long today, so I know for sure it works  However, I haven't tried with IcedTea on Ubuntu, so there could be some strangeness there too.

Glad it's not futile!

Hmm...  Bellow is the closest thing I could find to a stack trace, but I'm having trouble reading it.  The rest of the error log (huge!) is a lot of memory addresses and an ls -l of the libraries, don't think that'll be too useful.  It'd be somewhat surprising if the problem were in my code, because the product works fine inside eclipse, but then again, I'm pretty far out of my element  when it comes to compiling java to native binaries.  I can try exporting the product on my windows box when I get home from work, see if I have any more luck.

Thanks!
Nick

Stack: [0x00007f9091cc7000,0x00007f9091dc8000],  sp=0x00007f9091dc4600,  free space=1013k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libpthread.so.0+0x93c4]  pthread_mutex_lock+0x4

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(J)V+0
j  org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(J)V+8
j  org.eclipse.swt.widgets.Display.eventProc(JJ)J+132
v  ~StubRoutines::call_stub
j  org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(JZ)Z+0
j  org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(JZ)Z+9
j  org.eclipse.swt.widgets.Shell.setVisible(Z)V+246
j  org.eclipse.swt.widgets.Shell.open()V+11
j  org.eclipse.jface.window.Window.open()I+34
j  org.eclipse.ui.internal.WorkbenchWindow.open()I+24
j  org.eclipse.ui.internal.Workbench$24.runWithException()V+4
j  org.eclipse.ui.internal.StartupThreading$StartupRunnable.run()V+1
j  org.eclipse.swt.widgets.RunnableLock.run()V+11
j  org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Z)Z+29
j  org.eclipse.swt.widgets.Display.runAsyncMessages(Z)Z+5
j  org.eclipse.swt.widgets.Display.readAndDispatch()Z+61
j  org.eclipse.ui.application.WorkbenchAdvisor.openWindows()Z+44
j  org.eclipse.ui.internal.Workbench$33.runWithException()V+27
j  org.eclipse.ui.internal.StartupThreading$StartupRunnable.run()V+1
j  org.eclipse.swt.widgets.Synchronizer.syncExec(Ljava/lang/Runnable;)V+121
j  org.eclipse.ui.internal.UISynchronizer.syncExec(Ljava/lang/Runnable;)V+91
j  org.eclipse.swt.widgets.Display.syncExec(Ljava/lang/Runnable;)V+108
j  org.eclipse.ui.internal.StartupThreading.runWithoutExceptions(Lorg/eclipse/ui/internal/StartupThreading$StartupRunnable;)V+7
j  org.eclipse.ui.internal.Workbench.init()Z+240
j  org.eclipse.ui.internal.Workbench.runUI()I+409
j  org.eclipse.ui.internal.Workbench.access$4(Lorg/eclipse/ui/internal/Workbench;)I+1
j  org.eclipse.ui.internal.Workbench$7.run()V+73
j  org.eclipse.core.databinding.observable.Realm.runWithDefault(Lorg/eclipse/core/databinding/observable/Realm;Ljava/lang/Runnable;)V+12
j  org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Lorg/eclipse/swt/widgets/Display;Lorg/eclipse/ui/application/WorkbenchAdvisor;)I+18
j  org.eclipse.ui.PlatformUI.createAndRunWorkbench(Lorg/eclipse/swt/widgets/Display;Lorg/eclipse/ui/application/WorkbenchAdvisor;)I+2
j  nickburner.Application.start(Lorg/eclipse/equinox/app/IApplicationContext;)Ljava/lang/Object;+12
j  org.eclipse.equinox.internal.app.EclipseAppHandle.run(Ljava/lang/Object;)Ljava/lang/Object;+135
j  org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Ljava/lang/Object;)Ljava/lang/Object;+103
j  org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Ljava/lang/Object;)Ljava/lang/Object;+29
j  org.eclipse.core.runtime.adaptor.EclipseStarter.run(Ljava/lang/Object;)Ljava/lang/Object;+149
j  org.eclipse.core.runtime.adaptor.EclipseStarter.run([Ljava/lang/String;Ljava/lang/Runnable;)Ljava/lang/Object;+183
v  ~StubRoutines::call_stub
j  sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j  sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
j  sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
j  org.eclipse.equinox.launcher.Main.invokeFramework([Ljava/lang/String;[Ljava/net/URL;)V+211
j  org.eclipse.equinox.launcher.Main.basicRun([Ljava/lang/String;)V+126
j  org.eclipse.equinox.launcher.Main.run([Ljava/lang/String;)I+4
j  org.eclipse.equinox.launcher.Main.main([Ljava/lang/String;)V+10
v  ~StubRoutines::call_stub

Hi

I reported a bug in Eclipse bug tracker because it crashes with OpenJDK 1.7, maybe it explains your crash, it is only a supposition.

I've seen problems similar to this before when running Eclipse on Linux -- it looks like a bug between SWT and GTK, not a JOGL bug. I've also noticed I can get crashes like this on Linux if I try to set breakpoints inside some parts of the SWT source code.

You might try one or more of the following: updating Eclipse, updating your Ubuntu version (if you can do it without moving to 11.10, if you don't like the new UI), updating GTK, updating JVM (or trying the Oracle JVM).

Any update on this? We are seeing this error on our Linux builds. It's intermittent, but consistent enough to be a no-go for our customer. It seems to only occur if the OpenGL view is one of our starting views on launch and competes against other view/editor parts. We really need a solution for this.

BTW, we are seeing it on ubuntu 10.10, 12.04 32 and 64 bit, as well as CentOS

Hi

I use CentOS 5.3, 64 bits Intel. As far as I know, it does not come from Java, there is a problem with WebKit. I don't know how I worked around this problem, I don't reproduce it any more.

This may be the same as https://jogamp.org/bugzilla/show_bug.cgi?id=603, which I'm checking into now. There may be some thread interaction between JOGL and SWT through pthreads that is causing a problem. I can reproduce it on Ubuntu 12.04 with Eclipse 3.7.2 and Oracle's Java 1.6.30. You can CC onto the bug report to get updates.

There is nothing preventing concurrent access to GTK and that's a "common" source of crash under GNU Linux.

Edit.: I have found my previous bug report:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=375805
https://bugs.openjdk.java.net/show_bug.cgi?id=100246

Don't forget this for WebKit:
http://www.eclipse.org/swt/faq.php#howusewebkit

If your crash comes from XUL, use that argument:
-Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null

Edit.2: bforrester, your crash has nothing to do with my previous problems but I don't reproduce it here because I never use org.eclipse.swt.opengl.

Thanks for the rapid update Wade. We essentially ran the same tests you described in your ticket. It does seem to be some sort of race condition since we see one of 3 states occur when the app runs:

1) The pthread error as described or
2) The app hangs on window initialization or
3) The app launches and behaves perfectly fine from there on out.

We also notice that if an OpenGL window is not part of the initial opened perspective we don't have any problems (no problems on initializing a GL window after the app fully starts). For what it's worth we are using the AWT_SWT  method you posted Wade, with the 2.0rc8 build under both 3.6 and 3.7 target platforms using Oracle Java 1.6.xxx and 1.7. The heavy weight SWT/GLCanvas didn't work for us to support Windows, Mac, and Linux.

I will definitely subscribe to the ticket and follow this closely. This is pretty important for us since a significant amount of our customers are on Linux and our old solution (the Sun 1.0.1 lib with heavyweight SWT/GLCanvas) is beginning to show its age :)

Thanks again for your feedback and looking into this.