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.

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.

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.

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.

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.

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.

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.

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.

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.

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 <edit> Fixed typo

Especially as LWJGL is actually implemented on top of AWT now for Linux and OSXjust like JOGL is

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.

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