JSR-231 SWT Implementation development

[Mithrandir]

OK, general question for the community here. I have a GLCanvas implementation (not the org.eclipse.swt.opengl.GLCanvas) that just extends canvas. From that you can gain access to the underlying GLDrawable instance used for rendering. However, the canvas itself does not extend GLDrawable as that seems like a really badly confused design. I'd like to add the GLAutoDrawable capabilities. Any preferences on the way I would do this?

[Mithrandir]

OK, Time for people to give it a burl. Head over to http://opengl.j3d.org/swt/download.html and download it. It is only for Win32 right now.

You'll need SWT 3.2M3 or later and also you must use the provided version of JOGL with the download. I've had to hack on the RI code to stop it crashing when using SWT so make sure you don't have the old one there. If you get exceptions about class cast exceptions when you run the example apps, that means you haven't yet removed the RI JOGL from your classpath. I've offered the modifications back to Ken, but not sure if he's interested. As such, no source for the modified JOGL code just yet. If he doesn't take them, I'll fork the codebase and maintain our version on j3d.org. There's several other changes I'd love to make to the RI codebase, but they're mainly for longterm maintenance and more readability. They have nothing to do with the SWT implementation requirements. We'll see if Ken wants these changes first, then go from there.

Oh, one other thing to note - the APIs for GLDrawableFactory have changed a fair bit since the JSR Beta 1 release. These are the API changes already apparently approved by the JSR committee, but there hasn't been a JOGL RI release yet to show those to the world. Basically, anything that was creating a GLCanvas/GLPanel  from the factory are gone and you can directly instantiate them now. However, since you're using SWT, that won't matter. Download the examples files and have a look at the 3 different ways of using JOGL with SWT widgets and cut and paste those for now. My code currently has no equivalent for the GLAutoDrawable functionality. I want to do something like that, but the fact that GLAutoDrawable unnecessarily extends an interface with AWT-specific concepts in it is preventing me from doing so. Unless the JSR changes that, I won't be doing anything along those lines.

I'll now head over to the Aviatrix3D and Xj3D codebases and add SWT capabilities to those. I've not really tried this code with anything other than the simple demos so far. I have no idea how well the pBuffer code will work with this stuff. We'll see shortly once I have some code that stretches JOGL in all sorts of unusual ways

[Edit: Fixed typo in download link]

[Mithrandir]

Another update

SWT with Aviatrix3D is running nicely. I want to do one more minor bug fix with the context handling on shutdown and then I'll post an Aviatrix3D 2.0 beta 1 for people to play with, as well as some examples. If you'd like code in the mean time, fire me a private email at the usual address. Attached a simple image of my desktop with the very simple animation demo showing.

Games published by our own members! Check 'em out!

[K.I.L.E.R]

Very nice!
JOGL is progressing very fast indeed.

[Mithrandir]

Another update. We now have the SWT JOGL code available as a full Eclipse Plugin. Again, it's for Win32 only right now.  Head to http://opengl.j3d.org/swt/download.html and see down the bottom for the plugin zip file download. You should be able to just take and unzip the contents of that zip file straight into your Eclipse plugins directory and have it immediately available to use. I don't have a source plugin yet available to use, so you'll need to grab the javadoc from the 0.1 release to know what is going on.

I'm hoping tomorrow that I'll be able to post about the Aviatrix3D Eclipse Plugin as well, for those of you that prefer working with a scene graph. I have it all up and running, just missing a few config requirements on my work machine to build it here. Need to update that from what I have on my laptop.

[Shanus]

1) What do I need to do to create a new project in Eclipse that will make use of these plugins?

2) I was also wondering whether anyone has created an eclipse plugin with a view that uses these plugins?

If I can get a hand with 1 above I want to do 2, so any pointers would be appreciated.

- Shane

[krausest]

1) What do I need to do to create a new project in Eclipse that will make use of these plugins?

2) I was also wondering whether anyone has created an eclipse plugin with a view that uses these plugins?

If I can get a hand with 1 above I want to do 2, so any pointers would be appreciated.

- Shane

Seems I missed some of the points of the above discussion completely, but I can confirm that snippet 209 ( http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet209.java ) works fine for current JOGL builds and SWT 3.2M5. Maybe you can create your own plugin without too much effort based on the snippet.

[Mithrandir]

The download pointed to in my previous post works as an eclipse plugin. Just drop it into your plugins directory and off you go. I'm currently working with a slightly later version, currently for some demos we've been doing.

Apple stuff is still a long way off. I discovered that Sun's JOGL implementation talks to the windowing system interface through Cocoa. Unfortunately SWT uses Carbon and mixing the two is not possible. I've had to start again from scratch. I've got our code generating the AGL interfaces now, but haven't had the time to go back and work on the AGL to JSR bindings implementation. I need to do about a week's worth of work on another project and then I can jump back into getting that to work on all platforms. I do have X11 going, but something in one of Ken's recent changes are causing major flashing problems on my machines so I have to go trace down exactly what broke.

[Ken Russell]

One major thing that changed recently is how the locking is performed on the underlying GLDrawable object when making a context current and releasing it. Now the GLDrawable is no longer locked between the makeCurrent()/release() calls. This allows multi-head rendering on X11 platforms in particular. I wouldn't be surprised if this change affected the behavior of the SWT port as I have no idea how your port is doing its locking. You may want to try specifying the system property -Djogl.GLContext.noopt on the command line and seeing whether it affects the behavior of the SWT port. If it does, look around in the X11 implementation to see how the field GLContextImpl.optimizationEnabled is tested.

[Shanus]

The eclipse plugin only works if you use the Eclipse JRE as your runtime JRE, if you want to use a separate JRE then the eclipse plugin doesn't work.

I will have a look at the Java Snippet and see how I go from there. I am still only new to Eclipse plugin dev, but I did notice that the Views and Editors take a SWT Composite..

- Shane

Games published by our own members! Check 'em out!

[Shanus]

I am getting the following error when trying to use that plugin:

eclipse.buildId=I20060223-1656
java.version=1.4.2_11
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_AU
Command-line arguments:  -os win32 -ws win32 -arch x86

Warning
2006-03-25 15:20:22.468
Missing Fragment Host: org.j3d.opengl.swt

[Mithrandir]

Sorry I'm a bit slow on the replies here. Brain has been elsewhere and keep forgetting to check these forums.

The way the plugin is constructed uses a host plugin and a plugin fragment for the individual per-platform bits of code. This is the same way that SWT works itself. Basically there is a very small skeleton plugin that is a placeholder for the real code. This skeleton is what other plugins refer to (you'll see they always ask for org.eclipse.swt for example, not org.eclipse.swt.win32.win32). The Fragment then provides the real implementation without application code needing to know exactly which platform you're on.

In your plugin loading, make sure that you specifiy org.j3d.opengl.swt as the plugin that is required in the Required-Bundles attribute. Do not have it reference the platform-specific plugin name.  If you are not using the automatic update manager in Eclipse, then you need to specify both the generic host plugin and the platform-specific plugin name in your config.ini file.

[Mithrandir]

Just a small note of news. I now have the Mac version running successfully. It hasn't had much testing yet, but I can run the full set of Aviatrix3D apps over the top of it without too many issues. I've seen a couple of odd timing-related exception traces so those will need chasing down shortly. However, my intention is to release versions of both the SWT port for all platforms by the end of the week, and a couple of days later the first milestone release of Aviatrix3D 2.0 with SWT support as well.