What are the differences between them?
http://bytonic.de/html/benchmarks.html has reference to fastjogl . Is fastjogl available as standalone binding outside of Jake2?
Why does JNI have so much overhead?
How do the bindings perform on Linux and Mac?
LWJGL provides bindings to both OpenAL and OpenGL and does this mostly through NIO buffers which are reputed to be faster on the native side but are harder to use.
JOGL provides bindings to only OpenGL, thought there is JOAL for OpenAL.
LWJGL has been around considerably longer and has gone through more iterations of developer. JOGL is backed by SUN and tends to get more support on these forums. LWJGL has more examples of quality games but JOGL has slightly more documentation.
I don’t believe fastjogl has been made available by the Jake team.
The bindings on Mac and Linux have around the same performance penalty as they do on Windows. i.e. you’ll get about 90-95% of the performance on non-trivial scenes. Microbenchmarking this will show considerbly worse performance.
Kev
fastjogl is not a OpenGL binding. It is a different rendering pipepline in their game. It’s a renderer that uses vertex arrays instead of glBegin() and glVertex3f() etc.
I’ve tried LWJGL on PC & Mac and found reasonable performance on both platforms, which is more than I can say for Java2D, which is really really slow on my Mac. I’ve tried JOGL too. Both LWJGL & JOGL give a thin veneer over OpenGL so there’s not a huge amount of difference from a programming perspective. JOGL passes data in arrays, while LWJGL passes data in NIO buffers, which are a touch trickier to use, but result in less data copying behind the scenes, and so should be faster.
Although the most important difference hasn’t even been mentioned yet - Jogl’s reliability is terrible compared to LWJGL, even more so when you attempt to do fullscreen.
FUD. Show some stats.
I considered switching from jogl to lwjgl in wurm, but found the bugs in jogl far less annoying.
AFAIK, the mouse focus problem still hasn’t been fixed in LWJGL.
Only my personal experience with writing some pretty big Jogl and LWJGL apps. Anything other than a current nVidia card will likely not work with Jogl out in the real world. >:(
That’s funny, Wurm has a lot of ati users.
Go figure.
Most of ATI problem is not JOGL related but related to issues with ATI OpenGL drivers and those issues will bite any developer regardless of language (C/C++/Java/Haskell…) and binding LWJGL, JOGL etc. Speed, stability etc. is completely binding independent and has nothing to do with JOGL or LWJGL it all depends upon your app. So use the binding that you for some reason feel more comfortable with since it’s the only thing that matters.
// Tomas
That’s not strictly true. There are a couple of issues with JOGL to do with how it gets fullscreen and its integration with AWT which render it slightly less reliable. This is to be expected, as LWJGL actually has a completely custome display that was engineered specifically to work whereas JOGL is retrofitted to AWT.
IMHO the biggest real difference between JOGL and LWJGL is the API style; LWJGL is a C-Like static library with thread context functions and JOGL is some sort of odd OO abstraction of the whole concept.
Cas 
[quote]There are a couple of issues with JOGL to do with how it gets fullscreen and its integration with AWT which render it slightly less reliable.
[/quote]
Yes there are a few JOGL context issues… but they are not a problem as long as you do the init in certain order and remember the flag -Dsun.java2d.noddraw=true. If your refer to that AWT don’t support true full screen, only simulated, on linux then it’s a real issue if you need it but the issue is AWT as you pointed out. Yes, AWT/SWING can be a blessing and a nightmare, it’s java style and people tend to know and it has some real strength… but also some annoying limitations and quirks.
[quote][IMHO the biggest real difference between JOGL and LWJGL is the API style; LWJGL is a C-Like static library with thread context functions and JOGL is some sort of odd OO abstraction of the whole concept.
[/quote]
I totally agree with you. LWJGL is a horribly C-Like static library and JOGL is bit nicer OO abstraction of the whole concept. Although OO and OpenGL in the same sentence is contradiction in terms 
The whole concept relay boil done to taste. Use the library that feels and smells right for you. Skip the general “LWJGL vs JOGL” FUD comments you can find in various forums; they are both very good and competent libraries with small differences.
// Tomas
Its actually a good deal more complex then that simple sentance. For a good discussion of
where the over-head coems from in certain JNI operations see this classic text… (that I wrote
http://java.sun.com/docs/books/performance/1st_edition/html/JPNativeCode.fm.html#18062
Once you’ve read it, it will be much clearer to you why Native Direct Byte Buffers, which allow Java code to work directly with C-heap memory, provide so much improvement.
JNI overhead today is actually so small as to be trivial IF you use JNI correctly.
I can backup Markus’ statement (who didn’t agree to the above).
For my JOGL game project I’ve no real problems with window or fullscreen mode, aside the usual “ATI’s OpenGL driver can cause many more problems than Nvidia’s”…
I’ve had no problems with Nvidia graphic cards so far but a few with Ati’s. However the many workarounds in JOGL for exactly these ATI bugs solve the current issued. Of course you never know which bugs ATI’s going to “implement” in a future Catalyst, but Ken tends to react fast.
My game isn’t a Swing GUI’ed JOGL app. Maybe Orangy’s is? I only use a few Swing components laying next to the JOGL GLcanvas and these work with no problems.
Speaking for my game project (which isn’t finished yet), JOGL’s reliability isn’t terrible but actually very good.
The reliability issue is actually a bit anachronistic… JOGL had its ups and downs and LWJGL was always pretty consistently reliable, but they’re both now about as reliable as each other. Especially as LWJGL is actually implemented on top of AWT now for Linux and OSXjust like JOGL is
Fixed typo
Cas
This is the second time I have to correct you on this :). The linux implementation is not based on AWT (except for AWTGLCanvas of course). Only the AWT locking features are used, to provide synchronized access to X (which is not generally threadsafe). This is especially evident in fullscreen, where LWJGL has a fully featured fullscreen mode on linux, while AWT only has the lame fullscreen-sized-window.
Furthermore, the Mac OS X version of LWJGL is based on AWT alright, but is also providing some workarounds for some nasty bugs in Mac OS X < 10.4. Some of these workarounds are native code, so they would not as easily implemented in a JOGL client application.
- elias
Ok ok, partially implemented on top of AWT then :
Cas