Choosing between JOGL and LWJGL - help requested!

Newbie & Debugging Questions
#1

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?

#2

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/index.php/topic,14778.0.html
http://www.java-gaming.org/index.php/topic,18479.0.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.

#3

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)

#4

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.

#5

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

#6

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 :slight_smile:

#7

Will that affect current and older versions?

#8

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

#9

http://www.java-gaming.org/index.php/topic,21988.msg181266.html#msg181266

#10

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 :slight_smile: (it is a matter of days, I need to repair this at work).

#11

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?

#12

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 :slight_smile:

#13

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

So… ditto!

#14

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.

#15

Display.setParent()

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

#16

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.

#17

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

#18

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

#19

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

Cas :slight_smile:

#20

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

Mickael only said it is better to have some choices.

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 :slight_smile: