Choosing between JOGL and LWJGL - help requested!

[Chagma]

Let me start by saying that I am aware that A vs. B style threads are usually frowned upon but I feel this is the most suitable means for me to gain the knowledge I require.

We are about to embark on a large project using Java and OpenGL and I would appreciate some assistance on choosing between what appear to be the two main alternative libraries namely JOGL and LWJGL.

I am no expert on either of these but the main differences appear to be that JOGL has a larger footprint (which is undesirable but not necessarily a problem) and seems to have better in-built text rendering support (through the TextRenderer class) although it lacks any support for audio.  From comments on these and other forums it appears that LWJGL may be better supported and perhaps have a more promising longer term outlook.  Integration with either Swing and/or Java2D seems limited or non-existent in both libraries despite JOGL touting the Java2D/JOGL interoperability bridge (as this is profoundly broken).

Our requirements are basically for full access to OpenGL functionality from Java and this includes a need for good (excellent?) quality text rendering and effects.  The text will need to be scalable a-la vector graphics and be very legible at smaller font sizes.  The deployment method will be Java applets loaded using JNLP (yes true applets in a browser, not apps) so the library must work well in that environment.  Performance is critical of course but I am guess there's probably not much to distinguish the two libraries on that basis.

So, what are your thoughts on the two libraries and which do you feel would be the best fit for our requirements?  Are there perhaps other alternatives I am yet to encounter?

[Orangy Tang]

Fonts are not really something an OpenGL access layer should be concerned with, so I don't think you should be basing your decision on the built-in font capabilities of either library.

That said, it depends on whether you feel confident about writing your own font rendering system or would like to use an existing one. Jogl's font renderer basically just uses J2D to draw text and copies it to a texture for OpenGL display, so you could port that to LWJGL without too much difficulty.

Proper scalable fonts that work in both large and small sizes are technically difficult though, search the forums and there's some interesting stuff

http://www.java-gaming.org/topics/zshapes-resolution-independent-curve-rendering/14778/view.html
http://www.java-gaming.org/topics/valve-s-vector-text-rendering-method/18479/view.html

There's also Slick which has font rendering (albeit bitmap based so scaling may not be of great quality http://slick.cokeandcode.com/ ) and there's a few other gui libraries around which I can't find links for atm.

[ryanm]

Distance field rendering (the technique in OrangyTang's second link) works pretty well. Have a play on this webstart to get a feel for it.

Up and down to change the input font size, left and right to change the font.
Hitting space will cycle through rendering the raw texture, using the shader, and using the alpha-test fallback mode.
Hitting the left control key will toggle between distance-field and standard texture font rendering.
The last-typed character is rendered at 1/4, 1/2, x1, x2 and x4 scale, and then as large as will fit on the screen.
There's also a console that you can use to play around with the parameters of distance field generation - hit the grave key to activate it, "printconf" to see what's what, tab to autocomplete/get completion suggestions.

The code for this is freely available (webstart main class here, but the bit you'll be needing, and can easily extract without bringing the kitchen sink with it, is here)

Games published by our own members! Check 'em out!

[JL235]

It's not a huge advantage but because JOGL is signed by Sun it requires no certificates for the user to view (they are trusted by default). I believe LWJGL does which the user then needs to accept.

The TextRenderer in JOGL works and it does decent text. But it's far from perfect. First I've had multiple huge memory leaks because of how I've used the class and have since written management code on top to help handle it (namely that they don't seem to clean up their memory when you dispose them, so you should only have a limited number). I personally would like to replace it with something else. Second I've had a user who has said that some bits of text in one of my games was rendered multiple times, and some not at all. The rest of the graphics were not affected, only the bits using the TextRenderer (although this doesn't mean the TextRenderer is at fault in any way).

There is no reason why you can't use it, but IMHO if you have an alternative then you should use it.

[Orangy Tang]

It's not a huge advantage but because JOGL is signed by Sun it requires no certificates for the user to view (they are trusted by default). I believe LWJGL does which the user then needs to accept.

Jogl is no longer signed by Sun since they ditched the project.

[princec]

Signing isn't really a big deal anyway, if you pay for a certificate. If the user wants or needs the content, they'll click Yes.

Cas

[JL235]

Jogl is no longer signed by Sun since they ditched the project.

Will that affect current and older versions?

[Riven]

Will that affect current and older versions?

Even with older versions, by the time you finish your project, the certificate will probably have expired.

[Nate]

http://www.java-gaming.org/topics/jogl-java2d-opengl-bridge-does-it-actually-work/21988/msg/181266/view.html#msg181266

[gouessej]

JOGL does not have a large footprint and it has a better support of Linux (I have already posted one screen capture of a bug that has not been fixed for years in LWJGL and that has been reproducible on ALL Linux machines I tested, whatever the kernel version, Xorg version, window manager version, etc...). Sorry to speak once again about it but I have found no Linux machine that does not suffer of these broken desktop with straight lines on the task bar and in the background after using a LWJGL application that relies on the exclusive full-screen mode.

JOGL is used in the industry, in some scientific researches and in a few commercial games including Wakfu.

However, I am currently fixing a memory leak in the famous text helper called "TextRenderer", it will improve the memory footprint for sure  (it is a matter of days, I need to repair this at work).

Games published by our own members! Check 'em out!

[Chagma]

Thanks to everyone who has commented on this.

Perhaps I emphasised the need for good font rendering too much as this is only one of the requirements we have.  It's obviously a complex problem and it appears that some of the more advanced techniques would be equally applicable to either library.

I am interested in how JOGL and LWJGL stack up against each other in all areas.  Are there any major pros and cons (apart from font rendering) that have not been touched on that I should be aware of?

[princec]

The APIs are functionally identical; they both expose pretty much everything to do with OpenGL. LWJGL is slightly closer to the original C specifications, JOGL is slightly closer to what an OOP version of GL might have looked like, were it OO. LWJGL also includes OpenAL and comes bundled with JInput, and also includes a lightweight windowing library to bypass AWT that is aimed at games programmers. Both APIs integrate with AWT well.

The main difference is in support and general reliability. LWJGL is maintained actively by interested parties. JOGL is currently in an undetermined state and if history repeats itself like it often seems to, it'll go the way of Java3D.

Cas

[elias4444]

EDIT: Cas hit the post button before I did, and I basically said the same thing.

So... ditto!

[Chagma]

OK, that's a good summary - thanks.

One thing I do need to know re LWJGL is can its "canvas" (or equivalent container, whatever it's called) be used in a Swing program, perhaps inside a JPanel or inside a generic JComponent?  There doesn't need to be any fancy OpenGL/Swing integration, just the need for resizing and integration with the Swing rendering system.  I know this can be done with JOGL but I am not sure about LWJGL.

[Orangy Tang]

Display.setParent()

http://www.lwjgl.org/javadoc/org/lwjgl/opengl/Display.html#setParent(java.awt.Canvas)

[Chagma]

Right, so Display is their OpenGL root container (the equivalent of GLCanvas in JOGL)?  I see that setParent() takes a Canvas object which is AWT not Swing which may be problematic.

Also, does LWJGL support multisampling?  I know JOGL does.

[Orangy Tang]

Right, so Display is their OpenGL root container (the equivalent of GLCanvas in JOGL)?  I see that setParent() takes a Canvas object which is AWT not Swing which may be problematic.

Also, does LWJGL support multisampling?  I know JOGL does.

Multisampling is specified in the PixelFormat when creating a display:
http://www.lwjgl.org/javadoc/org/lwjgl/opengl/PixelFormat.html

Canvas being heavyweight hasn't caused problems when I've used it, because typically you're not overlapping any lightweight components (other than menus and popups, which can obviously be fixed with the appropriate Swing hint).

[dishmoth]

The APIs are functionally identical; they both expose pretty much everything to do with OpenGL. LWJGL is slightly closer to the original C specifications, JOGL is slightly closer to what an OOP version of GL might have looked like, were it OO. LWJGL also includes OpenAL and comes bundled with JInput, and also includes a lightweight windowing library to bypass AWT that is aimed at games programmers. Both APIs integrate with AWT well.

Presumably the idea of merging JOGL and LWJGL was abandoned because it wouldn't leave anything for JGO users to squabble pointlessly over...?

[princec]

Aye. JOGL also conveniently croaked, probably for the best, as there won't be any more time wasted on it

Cas

[gouessej]

Aye. JOGL also conveniently croaked, probably for the best, as there won't be any more time wasted on it

Cas

This is simply wrong. JOGL is alive. 3 people (including me sometimes) are still maintaining it.

Presumably the idea of merging JOGL and LWJGL was abandoned because it wouldn't leave anything for JGO users to squabble pointlessly over...?

Mickael only said it is better to have some choices.

The main difference is in support and general reliability. LWJGL is maintained actively by interested parties. JOGL is currently in an undetermined state and if history repeats itself like it often seems to, it'll go the way of Java3D.

Cas

JOGL is still actively maintained and it is not in an undetermined state. It is a community project that is still used in some 3D engines (Ardor3D, JMonkeyEngine, Xith3D, Aviatrix3D, ...). Stop FUD now please.

Mickael is working hard on JOCL. JOGL and JOCL can work together nicely

[Chagma]

OK, how many people are maintaining LWJGL for comparison?

[gouessej]

OK, how many people are maintaining LWJGL for comparison?

I don't know but they have no bug tracker and in my humble opinion, when it comes to Linux, they often quickly conclude the bug comes from the driver rather than their library... It happened at least twice in the past, I succeeded in proving once than I was right. Look at the LWJGL section here:
http://www.java-gaming.org/topics/lwjgl-example-doesn-t-work-under-linux-with-ati-radeon-9250-pro/19786/view.html

[Chagma]

This is proving to be a very difficult choice indeed!  There are pros and ons on both sides of the equation.  I guess I am concerned about the long term future of JOGL but that may be only a result of FUD as you say.  On the contrary, if the LWJGL team are not prepared to acknowledge bugs/faults in their own product and instead shift blame to external factors then that's a real worry too.

In the end I want something which just works (at least 90% of them time!), is supported, has a reasonable long term future and has the functionality I need it to have.  There doesn't seem to be anything in it on the functionality side so I guess it's going to come down to which library makes the most sensible and safe business decision.

That part is not so obvious, at least not yet.

[princec]

Actually I think what that post tells you is that the LWJGL devs are extremely quick and thorough and responsive when we get any bug reports, at all. We fix things as fast as possible and do a new release as soon as we can, as opposed to JOGL, which has been apparently frozen for quite some time.

And yes, gouessej does present some unusually pathological cases with weird versions of Linux with ancient graphics cards and OpenGL drivers. LWJGL is committed to providing stability for the vast masses and if we can't reproduce bugs because they're on fringe hardware the only solution is for gouessej to fix them himself and commit a patch once he's found out what's wrong. However, as we maintain, most of his problems come from buggy drivers (for example, his repeatedly documented display corruption from LWJGL fullscreen applications should simply not be possible from a desktop application, yet instead of bugging the driver writers he keeps hassling us instead - and so it will never be fixed).

Business wise, LWJGL is in safe hands. At the very least it's the foundation for Puppygames.

A list of contributors can be found on http://lwjgl.org/credits.php - we are many. The bulk of the coding work was performed by underground Danes, who receiving almost no visible sunlight for most of the year, have little better to do except maintain OpenGL bindings. These days much of the work is done by Spasi of these parts, who being Greek, has to turn out a monumental effort just to get out of bed most days let alone turn the computer on, yet somehow he has implemented all the OpenGL interfaces since 2.0 or something.

Cas

[dishmoth]

Mickael only said it is better to have some choices.

Yes, you get to choose which side to be on in a pointless flame war.

[gouessej]

And yes, gouessej does present some unusually pathological cases with weird versions of Linux with ancient graphics cards and OpenGL drivers.

No! I have asked some people to test on recent machines (gamers machines with some very recent ATI graphics cards) and I have tested at work with my workstation (NVIDIA Quadro FX, Intel Core 2 Duo, CentOS 5.3). I have tested with several distros, Ubuntu, KUbuntu, CentOS, Mandriva, Fedora, the results is the same. I have tested both with Gnome and KDE, the result is the same. I'm fed up with repeating the same thing.

Chagma, I encourage you to check it by yourself with a Live CD, it is highly probable that you will reproduce this bug.

Yes, you get to choose which side to be on in a pointless flame war.

This is not my decision, this is Michael's decision.

Concerning the maintenance, there are 3 people that share most of the job but there are some occasional contributors too. JOGL needs less maintenance effort because some painful steps have been automatized, the code that deals with JNI is generated, it does not use any hand-written template. Kenneth Bradley Russell now works for Google and as far as I know, he does not work on JOGL anymore. Sven Goethel left Sun some months ago and is currently a bit busy. Michael is very busy with JOCL.

[Nate]

This more like a flame pillow fight.

LWJGL FTW!

[jezek2]

No! I have asked some people to test on recent machines (gamers machines with some very recent ATI graphics cards) and I have tested at work with my workstation (NVIDIA Quadro FX, Intel Core 2 Duo, CentOS 5.3). I have tested with several distros, Ubuntu, KUbuntu, CentOS, Mandriva, Fedora, the results is the same. I have tested both with Gnome and KDE, the result is the same. I'm fed up with repeating the same thing.

That's interesting, there is quite high variety in your tests. What is your exact testing procedure? Weird thing is that I didn't observe such thing, nor did any of my users mentioned it to me. Also didn't saw anything like that from anyone other on this or other forums.

[princec]

No reports either from any of the several thousand Linux players of my games. Except gouessej.

Cas

[gouessej]

That's interesting, there is quite high variety in your tests. What is your exact testing procedure? Weird thing is that I didn't observe such thing, nor did any of my users mentioned it to me. Also didn't saw anything like that from anyone other on this or other forums.

We test the demos on lwjgl.org, especially "FullScreenWindowedTest". When we have some more time, we test some free demos including Puppy games. We are already 3 programmers to experience this problem with completely different hardwares. The only workaround I have found is to force AWT to reset the good display mode.