porting JOGL to SWT

OpenGL Development JOGL Development
#1

Hi all.

Recently I started to look into a way of integrating Jogl and SWT. I know that some work was already done but it was too distant from the original. My goal wast to only decouple the GLCanvas from AWT.

Unfortunately i found out that GLAutoDrawable heavily depends on AWT due to extending the ComponentEvents interface, which is basically a list of all events a AWT component handles. This makes the entire port much harder, as the whole “chain” that is derived from GLAutoDrawable has to be modified. :-\

My question is: Is there a reason for GLAutoDrawable to depend on AWT events? could it not be simply an list of jogl defined events that could be mapped to awt? Will I break everything if I change this?

Cheers
Tiago

[edit] typos :slight_smile:

#2

I’ve already done it.

http://opengl.j3d.org/swt/

And, yes, as you’re aware, JOGL is, unfortunately, tightly wedded to AWT, which means it is impossible to implement a conformant JSR 231 implementation for SWT.

#3

Hi Mithrandir!

First of all let me thank you for all your work on the swt port. I have been using it since i started using jogl on eclipse.

However I have two major issues with your work that i would like your input: :slight_smile:

  1. your implementation of the GLCanvas is quite different from the one on the JSR 231. It does not implement a GLAutoDrawable (I guess for the same reasons i pointed in my post above) and therefore losing some of the functionalities (?) provided by jogl.

  2. Why are there some packages hidden on the eclipse plugin, i.e. Texture. I know they are based on buffered images from awt however I do not feel that these classes are such a step back regarding the ones from swt.

Cheers
Tiago

#4

During the JSR-231 process we decided to use the built-in AWT events because there was no compelling reason to reinvent all of them. I believe it should be possible to bridge between these events and any SWT events without pulling in the AWT at run time (you could probably run the AWT in headless mode with -Djava.awt.headless=true and just use these events and listener classes, bridging to the underlying SWT implementations).

Another option would be for you to raise RuntimeException in your GLAutoDrawable implementation when any of these methods are called.

I haven’t looked closely at Mithrandir’s SWT port but we disagreed in the past about the structure it should take. I do believe it should be possible to build an SWT port of JOGL with minimal code – the GLDrawable and GLContext implementations are factored in a way to easily support this.

#5

To the best of my knowledge Mithrandir port does exactly that, it contains “SWT versions” for the factories that construct GLDrawable and GLContext. I use them and they allow the swift using jogl on swt.

However it is a petty that GLAutoDrawable should be so tied up to a AWT component. imho classes from awt like bufferedimage that are used for the texture handling do not bring such a drawback compared to the ones from swt but using a AWT canvas/component does. If this interface would be loosed coupled from the AWT component events it would be rather simpler to create a port for it.

Cheers
Tiago

#6

And can figure out the way you want to “port” OGL apps to AWT/SWT because of the hierarchical inheritage constraint that is focused here. Hence you have got with JoGL a component called GLPanel as well that can be added to some usual AWT Swing or SWT interface.
I used to have it as a direct rendering component but when I tried it versus a common Panel, it results in a holy mess with the refreshing rates. Therefore my 2D “engine” uses AWT/Swing only. But GLPanel is the perfect solution to get the OGL applications on air with AWT/Swing. you should be able to get out of this refreshing rates problem with 3D geoms etc.

#7

One of the major reasons for not extending GLAutoDrawable is the fact that it contains a completely unnecessary and pointless interface that pulls in all the AWT event classes. Simply importing that class and using it on Eclipse on a Mac causes the Mac to lock up the JVM solid. I don’t even have to call or make use of them. It’s the classloading of them that causes the problem. AWT and SWT are mutually incompatible on OSX. Doesn’t matter whether in headless mode or not. Simply firing up the AWT event model causes the lock because SWT uses one toolkit (Carbon) and AWT the other (Cocoa). Apple states flat out time and again on their developer websites that they are mutually incompatible and developers should never mix the two toolkits together.

The other major problem with the bottom of the JOGL source is that it has a very large amount of code that is designed to make the integration between Java2D and JOGL much smoother for JDK 1.6. In the bottom of the implementation the existing JOGL Threading class makes method calls and class references to the AWT event queue. The RI also then makes many many calls to an internal class called Java2D, which also either directly calls the Threading class or makes other calls into the AWT code that tickles the AWT event model, with the inevitable deadlocks on OS/X.

The biggest problem that I ran into was that there are so many layers of internal circular dependencies in the RI that it was not possible to cleanly extend it for SWT usage. I’ve used large chunks of the RI code, but heavily modified in many ways. I had to strip thousands of lines of code out of it to make it work (ie not deadlock) and also have some amount of long-term maintainability that was not dependent on the RI code. Another contributing factor to the large amount of differences it that SWT and AWT fundamentally act differently. AWT uses a lazy-loading approach to the widgets, SWT does not. The AWT widget can exist for a long time before the underlying operating system resources are allocated, where SWT has the native resource loaded before super() returns in the constructor. This forces many more intracacies on the AWT implementation than was needed for SWT. In fact, as I got through it, I found that many of the threading things that the RI had in it were causing problems for the SWT code. In stripping all that out, it made the code more reliable and conformant to the SWT implementation requirements. I struggled for months to keep the code in a state where you could run either the SWT or AWT components and still have things somewhat sane. However, it just cannot work given this completely different underlying implementation model, so I discarded the AWT code completely and made something that would actually work reliably with SWT (though I know there are still some timing bugs that I have yet to hunt down).

Quite simply, there is absolutely no way that an SWT version of the JSR 231 APIs can ever be conformant and run on all platforms that Eclipse runs on. The only way it could be is if the JSR group has a fundamental rethink about what an OpenGL API should provide, and what 3rd party widgets should provide. I don’t see that happening any time in the near future.

#8

I don’t have time to rebut this post point-by-point. However I believe that with judicious use of -Djava.awt.headless=true (perhaps setting this in the SWT GLDrawableFactory implementation) it would be possible to make the existing GLAutoDrawable interface work on SWT on the Mac. I believe it is possible to make a small set of source code modifications to the existing JOGL to work around the issues described with the Threading class forcing loading of the AWT, and if someone wants to do a port of JOGL to the SWT with fewer changes than described above I am more than happy to make changes to JOGL to enable it. Finally, the mention of “circular dependencies” is some notion that Mithrandir has that nobody else in the software industry that I have spoken to does. JOGL’s GLContext and GLDrawable implementations are cleanly factored and could easily be extended to allow SWT integration with just six new classes (WindowsSWTOnscreenGLDrawable, WindowsSWTOnscreenGLContext, etc.).