This thread is to track the development, and associated issues for adding SWT support to the JSR 231API set. FWIW, my company has a paid contract to develop formal bindings, and make sure that they work across at least Win32, Mac OSX, Linux x86 and Solaris/Sparc. I’m not going away on this topic any time soon 
Relevant link:
That tracks adding OpenGL SWT bindings. It also contains a link back to this topic.
Next post I’ll push in a few current issues and summary of things that need to be fixed.
Issue listing time:
There is no way of providing an alternate GLDrawableFactory. Typically this is done by providing an SPI interface and a system property used to define the instance of that interface to load. The current specification provides for none of this, nor any particular way of defining how one is supposed to create an alternate factory representation.
Creating Pbuffers is inherently AWT dependent. This is bad, particularly once one considers also needing them on JSR 239 code and J2ME, which doesn’t have AWT. The offending interface is ComponentEvents. There appears to be no logical reason for this interface to exist at the spec level as it is only providing an implementation-specific functionality. This should be removed and shifted off into the sun-specific implementation code.
I really don’t like the design of the GLDrawableFactory at all. I’m going to write up and propose a different design and send it off to the JSR team.
A JSR-231 provider can change the implementation of GLDrawableFactory as needed. At least for now the expert group decided not to go down the route of defining an SPI as this would add complexity to the API. If you want, we can try to define an internal SPI to the GLDrawableFactoryImpl and promote it to the public spec later.
The abstraction of ComponentEvents allows equal treatment of multiple kinds of GLDrawables, in particular GLCanvases and GLJPanels, so that applications can switch between them by changing one line of code. The fact that this interface references AWT event classes is a non-issue. All compliant J2SE implementations, even those which support the SWT, contain these classes. JOGL’s pbuffer implementation has no-ops for all of the ComponentEvents methods. Therefore, a JSR-231 implementation supporting the SWT could create GLPbuffers without running any code in the AWT and forcing the Toolkit to start.
If you have a better suggestion we would be glad to hear it.
[quote]A JSR-231 provider can change the implementation of GLDrawableFactory as needed
[/quote]
We’re not interested in providing a complete separate implementation of the JSR code. We want to make use of the existing bindings and code, where possible and just have the context bound to a different surface type. This is quite easy concept to do as both the SWT OpenGL work (just added in SWT 3.2 post M2) and LWJGL already do this.
[quote]At least for now the expert group decided not to go down the route of defining an SPI as this would add complexity to the API.
[/quote]
It doesn’t need to. I have a proposal here for a reworked GLDrawableFactory API that makes it completely implementation dependent, as well as windowing system API independent. I’ll send that off in a couple hours after Alan’s had a chance to read over it and comment.
[quote]The abstraction of ComponentEvents allows equal treatment of multiple kinds of GLDrawables, in particular GLCanvases and GLJPanels, so that applications can switch between them by changing one line of code. The fact that this interface references AWT event classes is a non-issue.
[/quote]
Theoretically true. In practice, that is not the case. Have a read through the above linked bug report and then the referenced reports from there. Even just referencing the AWT classes is causing problems on some platforms (ie JVM crashes et al). Of course, there is also the political issue. OpenGL, which itself is windowing system agnostic, is being forced to be specific windowing system. At least for the SWT people, that’s a very significant issue.
Anyway, just documenting some of the more public responses. I’ve got a couple of very detailed emails ready to send off to you after Alan and I discuss it a bit more. You should hear something in a few hours from us (he’s on phone meetings for most of the morning 
).
You can do this with the current JSR-231 code as well. See GLDrawableFactory.createExternalGLContext().
It doesn’t need to. I have a proposal here for a reworked GLDrawableFactory API that makes it completely implementation dependent, as well as windowing system API independent. I’ll send that off in a couple hours after Alan’s had a chance to read over it and comment.
[/quote]
I’m looking forward to seeing your proposal.
Theoretically true. In practice, that is not the case. Have a read through the above linked bug report and then the referenced reports from there. Even just referencing the AWT classes is causing problems on some platforms (ie JVM crashes et al). Of course, there is also the political issue. OpenGL, which itself is windowing system agnostic, is being forced to be specific windowing system. At least for the SWT people, that’s a very significant issue.
Anyway, just documenting some of the more public responses. I’ve got a couple of very detailed emails ready to send off to you after Alan and I discuss it a bit more. You should hear something in a few hours from us (he’s on phone meetings for most of the morning ).
[/quote]
I am not concerned with political issues regarding this JSR. However, if there are technical issues preventing an SWT binding from interoperating with it, we will take those issues seriously.
I don’t think that simply removing ComponentEvents as a superinterface of GLAutoDrawable is going to solve all of your window system- and pbuffer-related issues. On X11 platforms it is necessary to synchronize multithreaded access to the X server when performing GLX calls, and the JOGL implementation does this by grabbing the AWT lock where necessary. If an SWT library wanted to use JOGL’s pbuffer implementation then at least that portion of the implementation would need a different synchronization mechanism. It’s for reasons like this that I am very reluctant to commit to public APIs promising “platform independence” without a concrete working implementation. Frankly, if IBM was so interested in seeing this, they should have been actively participating in the development of the JSR instead of waiting until it was almost complete.
[quote]I am not concerned with political issues regarding this JSR. However, if there are technical issues preventing an SWT binding from interoperating with it, we will take those issues seriously.
…
Frankly, if IBM was so interested in seeing this, they should have been actively participating in the development of the JSR instead of waiting until it was almost complete.
[/quote]
Unfortunately, others are. There are political issues in everything that happens. In this case, it appears that by you having some personal beef with IBM, of which I know nothing about and you happen to bring up in response to my suggestions, is an entirely political response. All I see is that you are not interested in at least tripling the number of developers that would love to use this API, because of some personal issues you appear to be having with some other company that I have nothing to do with (FWIW, the number of developers that would use this in my client alone would match the current JGO community member numbers).
I’m asking for one relatively minor API change (shifting where ComponentEvents sits in the heirarchy) that would result in a very large development community being totally anti this specification to being totally for it. Most of the GLDrawableFactory stuff can be ignored if needs be (though defining a system property so that both an SWT and AWT implementation of this spec can happily coexist on the one machine would make life much, much easier).
Given this rather strange reaction, why would myself, my client, or IBM, for that matter, be interested in wanting to work with you and/or Sun to improve the spec or any other future spec for all concerned? Does this not reinforce the opinions that the SWT folks think that Sun is actively trying to destroy an extremely popular ongoing large-scale java development project, rather than working to bring even more developers to the Java table? This is not the sort of rift that is good for either community and I have no idea why you wish to make it so. Obviously politics is involved.
Edit: Bah, messed up the quote handling between preview and submit
From my point of view, SWT support is as much important as the whole JOGL project is.
What I mean is that their was already very good OpenGL bindings available ; what JOGL project has provided to the community is a very good specification that let us hope that we will have the possibility in a near future to stop discussing about porting from Gl4Java to LWJGL then to JOGL just to get the small improvements each library has on its competitor. The JSR-231 let us hope that in a near future, 3D application under java will stick to the “write once” part of the well known Sun definition of Java.
Therefore, it is more than important that peopple that are to contribute important extensions (native fullscreen, SWT support, …) could do so easily since, as I see it, it is the main aim of the whole JSR-231.
In short, I hope that this little rift won’t break Mithrandir or Ken willings to work together since being able to come with a pack “final JSR-231 + JOGL base AWT open-source implementation + SWT open-source (?) extension” is really important.
Vincent@Mithrandir: I don’t understand your reaction. Ken has made a valid point with his little sidekick. Maybe he has a personal issue with IBM, but who cares? I am reading this forum for a long time and I didn’t ever get the feeling, that Ken is not willing to help.
Maybe you should take his concerns seriously and continue to discuss the technical issues instead of verbally attack people you need to help you. Keep in mind, that this is a JSR with a lot of work already done by these people, so I think respecting their opinions on this matter should be important to you. Also if you have ever worked with people from different backgrounds and different employers you should know, that cooperating in this context is complex and needs a lot of patience…
Just my 2 cents.
Mithr. is occasionally rather blunt in his analysis, but then, Ken can be rather offhand and NIH… I can quite see both of you getting rather upset over what appears to be a fairly trivial issue to fix… and I can’t really see why Ken has a problem with it? The political issues are enormous. The whole JOGL project was shrouded in controversy from the start. Mithrandir may or may not be interested to know that LWJGL is to be built in to Eclipse in the not-too-distant-future as the standard binding (as I understand it, Matzon / Elias correct me if I’m wrong there) because we bend over backwards to make it compatible when people ask for small changes.
Cas
Guys, calm down a bit please.
Since the initial comments on the JOGL implementation were mine (in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=110757 ), I would like to clarify several things a bit.
No question JSR public classes/interfaces referencing AWT stuff is ugly; yet Ken is probably correct that this is not a showstopper, especially in relation to bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=67384 , which is about SWT+AWT on MacOS X crashing the JVM. As far as I understand, these can co-exist as long as AWT is running in headless mode. Now, the interesting questions are a) can JOGL run if AWT is in headless mode - probably not; b) is the hard dependency of JOGL.DLL on JAWT.DLL a problem on MacOS X. These problems, IMO have to be fixed first, if JOGL-the-implementation is to be used with SWT.
As for the JOGL needing to hold the AWT lock, can’t this be abstracted somehow? I’m actually not yet sure if this also applies to SWT. As far as I know, SWT/GTK+ and SWT/Motif also has a "lock " (sort of) that is used when entering the GTK+/Motif natives. This lock is actually a regular Java monitor, just like in AWT I think. This is needed because in SWT, using a graphics context (GC) from a worker thread is allowed, and while this is more the exception than the rule, this brings some sort of multithreading in SWT as well. I’m not sure yet if this applies to SWT+JOGL, i.e. if JOGL has to hold the same lock when calling into GLX. After all, JOGL will use a separate display connection (with XOpenDisplay)…? Will this mean that we shouldn’t care about XLIB reentrancy problems?
Cas,
[quote]LWJGL is to be built in to Eclipse in the not-too-distant-future as the standard binding
[/quote]
Well, I doubt they are going to hardwire or prepackage LWJGL with SWT, but who knows?.. And they don’t need to - the way the toolkit cooperates with LWJGL for context management implies that neither side (toolkit and LWJGL) needs to know anything about the other.
I’m only worried about the locking thing…
Yes, that’s the idea. But whatever - I think that JSR231 needs to address Mithrandir’s point, that there is an interdependency which is not necessary for JSR231. He’s right that this is basically an implementation of the spec rather than the spec itself.
Cas
I think (a) can be made to work fairly simply. The SWT-based GLDrawableFactory would in general override methods which would prevent the AWT from being loaded anyway. Of course the supplied AWT-based GLCanvas, etc. would no longer work in this mode but this wouldn’t be the intent anyway.
For (b), I believe we can refactor the dependence on the JAWT in JOGL into a separate native library loaded on demand. All of the (non-autogenerated) uses of the JAWT in JOGL are done from Java code which makes this an easier proposition than in some other libraries.
It can absolutely be abstracted out; this has already been done in the JOGL implementation, although because this concept is inherently platform-specific it has not been exposed in the public API.
I think an SWT-based JSR-231 implementation could work and still share significant amounts of code with the JSR-231 RI (for example, the pbuffer implementation) by subclassing e.g. X11GLDrawableFactory and overriding certain methods. Does this sound like a reasonable approach? Of course it would be possible for an SWT-based implementation to completely reimplement the GLDrawableFactory but this would result in no code sharing. Given all of the implementation details and differences among platforms I don’t currently see how to allow the SWT implementation to use things like JOGL’s pbuffer implementation or on-screen OpenGL context management code by introducing new concepts in the public API abstracting away things like the “window system lock” or a “drawing surface object”. There are inherent differences in how these things are done among platforms making the current GLDrawable and GLContext abstractions good ones for public specified APIs.
At least from my personal implementation perspective, I would like to reuse as much of the RI code as possible and just sub out the SWT bits as needed. That’s basically because I want to be lazy and let all the good work that has been done so far continue to be used. The auto generation of the GL code is really handy to have. However, considering that the model that SWT uses for handling the native pointers versus what AWT uses (direct versus lazy loading), there’s going to be quite a bit of implementation differences going on there. As such, I suspect there won’t, in the end, be as much reuse as I’d like to have. That’ however, doesn’t degrade the aspects that I’d like to see changed at the API level, which is the points I’m trying to get across here. Implementation bits are secondary to that debate.
Our biggest implementation issue, as noted in the above Eclipse bug, is dealing with the OS X implementation of AWT. Unfortunately, in this case, Apple really does stick to their moto of “Think different”. I’m documenting some of the just plain weird stuff their classloader system gets up to in an email right now to Ken. We hav had, and continue to have, a whole slew of OS X bugs in Xj3D/Aviatrix3D that we never see on any other platform or JVM (Sun, or IBM) that are almost all related to the classloader or AWT. Yesterday I ended up doing some Xj3D work and so just now catching up on a couple of days worth of comments from all sides.
As for the LWJGL/SWT comments above. At least from what I’m seeing of their current CVS code, there is no integration directly by the eclipse project. LWJGL can run on a SWT Canvas, but the API work that’s in the current SWT is a pure GL 1.1 set of APIs that appear to be hand-cut. There seems to be some significant differences from the LWJGL APIs, (see the SWT GLCanvas implementation), so I doubt they’re the same thing.
You are right, they are different implementations. The SWT binding is itself a cut-down bare bones 1.1 GL API, as I understand it. That’s why there is interest in taking on the LWJGL, as it’s a full binding, without any windowing system integration problems. Kinda like the JSR231 spec should be.
Cas
Aha: http://download.eclipse.org/eclipse/downloads/drops/S-3.2M3-200511021600/eclipse-news-M3.html
Cas
At that link just below the SWT/LWJGL OpenGL thing it also states “Buttons can now show an image as well as text.” — um… that is new and noteworthy??
SWT bugs me. It seems to be such a waste of time and resources.
Well, the performance of SWT IS better (and thats without an OpenGL, which Sun has had to resort to), and it also scales to embedded systems.
That said, I still prefer AWT
I prefer AWT as well, but only because it’s easy to start with and Swing is familiar now. For real GUI programming SWT is increasingly excellent.
Cas
For general UI work SWT doesn’t appear to have any significant performance advantage, that’s comparing to Swing without any HW acceleration. By that I mean it could be 10 times faster, but it doesn’t matter because Swing is still responsive when programmed correctly. Swing does not “feel” any slower than SWT as far as I can tell.
I’ve programmed Swing UIs for years now, and since at least Java 1.3 I have never made a single one that was “slow”. In the Java 1.2 days you could end up with something a bit slow if you weren’t careful.
Combined with having to bundle SWT for each platform and it just makes no sense. SWT was a wasted effort and should be abandoned.
I have spoken, let it be so