Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (117)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  JSR-231 SWT Implementation development  (Read 9018 times)
0 Members and 1 Guest are viewing this topic.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Posted 2005-11-01 20:48:40 »

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 Smiley

Relevant link:

Eclipse Bug ID 110757

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.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #1 - Posted 2005-11-01 21:00:39 »

Issue listing time:

1) 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.

2) 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.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #2 - Posted 2005-11-02 00:44:55 »

1) 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.

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.

Quote
2) 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.

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.

Quote
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.

If you have a better suggestion we would be glad to hear it.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #3 - Posted 2005-11-02 18:52:19 »

Quote
A JSR-231 provider can change the implementation of GLDrawableFactory as needed

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.

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.

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 Sad  ).

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #4 - Posted 2005-11-02 19:33:21 »

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.

You can do this with the current JSR-231 code as well. See GLDrawableFactory.createExternalGLContext().

Quote
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.
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.

I'm looking forward to seeing your proposal.

Quote
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.

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 Sad  ).

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.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #5 - Posted 2005-11-03 07:55:42 »

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.

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

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Niwak

Senior Member


Medals: 1
Projects: 1



« Reply #6 - Posted 2005-11-03 08:58:46 »

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
Offline cylab

JGO Ninja


Medals: 49



« Reply #7 - Posted 2005-11-03 10:04:56 »

@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.

Mathias - I Know What [you] Did Last Summer!
Online princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2005-11-03 10:20:31 »

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 Smiley

Offline ivanm

Senior Newbie




I love YaBB 1G - SP1!


« Reply #9 - Posted 2005-11-03 11:31:10 »

Guys, calm down a bit please. Smiley

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.

1. 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.

2. 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?


Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ivanm

Senior Newbie




I love YaBB 1G - SP1!


« Reply #10 - Posted 2005-11-03 12:00:20 »

Cas,

Quote
LWJGL is to be built in to Eclipse in the not-too-distant-future as the standard binding

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..

Online princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2005-11-03 15:39:50 »

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 Smiley

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #12 - Posted 2005-11-03 20:12:32 »

Guys, calm down a bit please. Smiley

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.

1. 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.

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.

Quote
2. 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?

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.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #13 - Posted 2005-11-04 18:57:47 »

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.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Online princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2005-11-06 11:19:59 »

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 Smiley

Online princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2005-11-06 18:40:06 »

Aha: http://download.eclipse.org/eclipse/downloads/drops/S-3.2M3-200511021600/eclipse-news-M3.html

Cas Smiley

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #16 - Posted 2005-11-07 00:26:05 »

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.

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #17 - Posted 2005-11-07 07:00:35 »

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 Smiley

Online princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2005-11-07 10:30:21 »

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 Smiley

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #19 - Posted 2005-11-07 23:05:38 »

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 Smiley

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 Smiley

Online princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2005-11-08 17:19:27 »

What would be just excellent is SWT being adopted by the JDK, and then AWT refactored on top of SWT.

Cas Smiley

Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #21 - Posted 2005-11-08 18:38:59 »

Heh, fat chance of that happening. Smiley

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #22 - Posted 2005-11-09 03:09:33 »

What would be just excellent is SWT being adopted by the JDK, and then AWT refactored on top of SWT.

Well then you truly do have a lot fo redundant code in the JRE with SWT and Swing.  And quite frankly I would rather have Swing, since it is "more java" and I *assume* would therefore be much easier to customize.  (I've customized lots of Swing stuff, but I haven't programmed SWT and likely never will.)

Anyway as far as JSR-231.. if it can work with SWT, great.  If it can't. I couldn't care less.  Sounds like it *can*, so there you go.  If it is *harder* I also don't care, that's what you get for doing something stupid like SWT. :-P

Ok ,seriously... Sun has done an abysmal job with the windows look and feel. JFileChooser remains so bad that end-users complain about it constantly and we actually lose sales because of it.  Until Java 5 pretty much everything else didn't quite match the native components as well.   But I would rather see the effort go in to fixing those issues than to do something like SWT.  I Sun had fixed those issues at a reasonable rate (still waiting for a usable JFileChooser on Windows after how many YEARS?) there would be no "need" for SWT.  It's mainly because in the earlier years (well shortly after they failed to get applets marketed properly) they totally disegarded the desktop side of Java...  I guess they didn't clue in that all those servers that they were selling might be able to make use of rich clients...

This is so totally off-topic that I must shut myself up now... sorry for the rant.

Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #23 - Posted 2005-11-09 19:01:43 »

SWT integration is one part of a bigger picture. OpenGL is platform agnostic. All it does is draw 3D things. Tehre are extension APIs (GLX, WGL et al) that provide it a handle to operate on.  While SWT is probably the most popular non-AWT toolkit, there are also several others, as well as the J2ME market to consider. The basic OpenGL interface should be as free from AWT as it should be from any other windowing-system specific API. Just happens that SWT is the focus for enforcing that requirement in the spec due mainly to its popularity. Note that the JSR writeup says nothing at all about AWT integration being required, just that it is an interface to OpenGL.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Cork

Junior Member




vote 6uN for OSX


« Reply #24 - Posted 2005-11-14 22:20:21 »

Having done AWT and Swing Gui development for many years now it was a pleasant surprise recently to be asked/forced to use SWT for a new rich client development project.  I did my best to defend Swing but I have to say Wow! I'm now totally converted.  Even with a much smaller feature set than Swing, SWT is much faster and feels the right tool for the job.  It's what AWT should have been in the first place IMO. 

So recently I was looking back at my JOGL Swing project which has been sat on a shelf for 6 months and now I'd really like to port everything to SWT asap.  So for now though I'm following these threads and the bug reports over on eclipse really hopeing that you guys can hammer out something thats going to blow away other rich client development tools Smiley  JSR-231 with SWT is the future of opengl development !!!  Please make it work nicely together, esp. full screen Smiley

Cheers

Peter
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #25 - Posted 2005-11-15 03:33:56 »

Even with a much smaller feature set than Swing, SWT is much faster and feels the right tool for the job.

What do you mean "Even with..." ?  With less features one might expect it to be a bit faster!  Though I can't see how any speed increase could possibly matter, it's a UI framework, and the user can only press the buttons so fast.  I can't work fast enough to make Swing feel slow.

What platform were you using when you compared SWT to Swing?  Do you get the same benefits on Linux and Mac? To the same degree?  Have you profiled applications that are identical except for Swing vs. SWT?  Can the casual user see a difference in performance that is significant enough to warrant the duplicated effort, extra downloads, etc?

Quote
It's what AWT should have been in the first place IMO.

Yes, I think this is exactly the case.  But it came far too late.  That ship has already sailed.  Now that we have Swing,with a richer feature set than SWT, working plenty fast enough, without hardware acceleration... well that leaves SWT serving no useful purpose.

Quote
...JSR-231 with SWT is the future of opengl development !!!

JSR-231 is the future of OpenGL development.  SWT will continue to be used by the minority.

But I agree in principle with Mithrandir,  so long as JSR-231 remains neutral in terms of the windowing toolkit, be it AWT, SWT, even LWJGL with the simple support for top-level windows and screens (and by neutral I mean simply that it can be made to work with either one of them, not that no AWT classes are referenced, after all AWT is part of the Standard Java core) - then in my view it meets its purpose.  Only if the AWT reference poses an true obsticle to these alternative implementations does something need to be done to address it.

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #26 - Posted 2005-11-15 06:33:54 »

Please make it work nicely together, esp. full screen Smiley
afaik, neither SWT nor JSR-231 mentions anything about fullscreen mode. You will have to use Swing or LWJGL for that

Offline ivanm

Senior Newbie




I love YaBB 1G - SP1!


« Reply #27 - Posted 2005-11-15 16:36:08 »

Let's not pollute yet another thread with the SWT vs. Swing argument!
Let's keep this place quiet, so that Mith & Ken can post *real*, *valuable* updates on the TOPIC of this thread: the *tech details* on how it is going (the port of JOGL to SWT, that is).

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #28 - Posted 2005-11-16 06:58:22 »

Mithrandir has made several valuable suggestions on restructuring in the public JSR-231 API as well as in the implementation to decouple the AWT-specific code from the rest of the window system-specific OpenGL-related code. These restructurings have been approved by the expert group (where necessary) and applied to the JOGL source base. At this point I think it should be fairly simple to plug in an SWT port. We have some disagreement as to exactly how that port should be structured but are continuing to discuss it.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #29 - Posted 2005-11-18 19:43:08 »

Code is done for the Windows version on my end, but not yet checked into my local CVS. I want to do some more testing first and then I'll post the details here for everyone to try out.  Code is under the BSD license, packaged and available under the j3d.org site setup.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Grunnt (18 views)
2014-09-23 14:38:19

radar3301 (14 views)
2014-09-21 23:33:17

BurntPizza (31 views)
2014-09-21 02:42:18

BurntPizza (22 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (29 views)
2014-09-20 20:14:06

BurntPizza (33 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (75 views)
2014-09-10 13:57:51

TehJavaDev (105 views)
2014-09-10 06:39:09
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!