I think that Java and OpenGl just weren't meant to be used together. I have used gl4java, JOGL, and have even given SWT's OpenGl wrappers a go. While SWT is the best of the 3 you are stuck using SWT. Other languages seem to be able to use OpenGl just fine. I'm not sure why Java and OpenGl cause such problems. I hope someone will leave me some comments as to why.
OpenGl is a state machine. You apply some changes to the state and it stays that way until you change something else. Now if I use C or C++, for example, I can modify that state machine from anywhere. As I should be able to do. With gl4java and JOGL I can only change the state from a specified method. Typically something similar to the display() method. This just isn't acceptable.
So I think to myself, why do I want a good Java OpenGl wrapper so badly? Why don't I just use C, C++, QT, or even C# for that matter (yes, C# has a very good OpenGl wrapper called TAO)? The reason is because I know the Java language. It's comfortable for me. Yes, I know C, C++, and C#. But not like I know Java.
The word is that it's because of SWING/AWT threading that causes problems updating the state machine from anywhere and it has to be very controlled for it to happen correctly and for things to play nice.
Well, I guess for the time being I will just stick with QT and C++ for all my OpenGl needs. But I hadn't posted anything on my blog for a while and a good rant was due.
OpenGl is a state machine. You apply some changes to the state and it stays that way until you change something else. Now if I use C or C++, for example, I can modify that state machine from anywhere. As I should be able to do. With gl4java and JOGL I can only change the state from a specified method. Typically something similar to the display() method. This just isn't acceptable.
So I think to myself, why do I want a good Java OpenGl wrapper so badly? Why don't I just use C, C++, QT, or even C# for that matter (yes, C# has a very good OpenGl wrapper called TAO)? The reason is because I know the Java language. It's comfortable for me. Yes, I know C, C++, and C#. But not like I know Java.
The word is that it's because of SWING/AWT threading that causes problems updating the state machine from anywhere and it has to be very controlled for it to happen correctly and for things to play nice.
Well, I guess for the time being I will just stick with QT and C++ for all my OpenGl needs. But I hadn't posted anything on my blog for a while and a good rant was due.
TrackBacks[0]
Comments[3]
Posted by gdboling on February 3, 2004 11:59:39 PM CST
Reply |
Permalink
Re: Fed up with Java OpenGl Ports
Hi Gregg,
you should be looking at LWJGL then, which does what you want it to.
Although it was designed for games programmers, and it comes with OpenAL, input, and a special standalone window manager separate from the AWT, it is a very straightforward Java-centric wrapper over the OpenGL state machine.
There's no object-orientated rubbish going on; OpenGL is a static library - so we've implemented it as static methods. Keep an eye out for the forthcoming 0.9 release, where the API is changing again to be even more straightforward.
It should work on top of the AWT if you use the basic features being provided in JOGL to set up a rendering context. JOGL as you know is Sun's officially endorsed but woefully-wide-of-the-mark GL wrapper.
Cas :)
Comment from Caspian Rychlik-Prince on February 4, 2004 5:56:21 AM CST
Check this out!
http://www.agency9.com/
to bad you need to licence it :(
Comment from obidobi on June 24, 2004 8:04:43 AM CDT
I know what you mean, but i dont have problems with SWT, it looks like when i usw C with SDL + Opengl, and the speed is not so bad, but no API YET, that pisses me off....well thats all
Comment from Osman Romero on September 7, 2004 1:52:56 PM CDT
TrackBack to http://radio.javaranch.com/gthought/addTrackBack.action?entry=1075874379000