JOGL vs LWJGL and the best way to start learning

[gouessej]

@Spasi

It wasn’t a design flaw, it was a design choice

It’s a matter of viewpoint.

@Spasi

What cost is that exactly? With JogAmp you need to pass GL instances around

It depends on what you mean. You can get it from anywhere as soon as the context is current, you don’t need to pass it.

@Spasi

, whereas LWJGL uses a ThreadLocal to store context data. If you mean the TL access, that’s dirty cheap. Last time I checked, the method call overhead in LWJGL is lower than JogAmp on all GL calls. Mostly by a small margin, but JogAmp can be up to twice slower on GL calls that accept buffers (e.g. glGetInteger(GL_MAX_TEXTURE_IMAGE_UNITS, buffer)). Not that it matters at all for properly written GL code, except maybe on low-power devices.

JogAmp is not twice slower.

[ra4king]

[quote=“Spasi,post:40,topic:39904”]

@ra4king

It’s already fixed in the Java 7 docs.

Oh sweet!

[Spasi]

[quote=“gouessej,post:41,topic:39904”]
Feel free to test it yourself: LWJGL test - JogAmp test

My results (Win 8 x64, Java 8 x64 Server VM, i5 Sandy Bridge 3.1GHz, latest AMD drivers):

LWJGL - glGetInteger - 18ns
LWJGL - glDepthMask - 12ns
LWJGL - glColor4f - 13ns

JogAmp - glGetInteger - 42ns (58ns with int[] instead of IntBuffer)
JogAmp - glDepthMask - 14ns
JogAmp - glColor4f - 14ns

Again, these numbers don’t mean anything in practice for real GL code, just want to back up what I said earlier with some data.

[princec]

I am sober now. Porting TUER to LWJGL suddenly seems like the most amazingly fuckwitted idea I ever had.
I might port JOGL to LWJGL though, which would be funny.

Cas

[nsigma]

@princec

I am sober now.

Wow, did it really take you three days to sober up?! (actually, reminds me of a friend’s recent stag do, but I digress )

@princec

Porting TUER to LWJGL suddenly seems like the most amazingly f**kwitted idea I ever had.

Ah, but sir, I believe we have it in writing that you’re going to do this …

@princec

I might port JOGL to LWJGL though, which would be funny.

Port NEWT to LWJGL - that would actually be useful and fun (no guarantees given on the latter! ;D )

[princec]

LWJGL does need a fundamental overhaul of its display architecture, but really, it’d be nice if there was an AWT system that was lightweight and well designed enough to Just Work with LWJGL in the first place. NEWT may indeed be a good start.

Cas

[masteryoom]

Isn’t JOGL the same as LWGJL except without the LWGJL code?(As in, the display). So, basically, the JOGL is like OpenGL, and LWGJL is that and extra? ???

[princec]

JOGL is a bit like the OpenGL part of LWJGL, except it’s got the irritating requirement of passing round a redundant “gl” instance everywhere, which from the API perspective, is plain wrong, and why we didn’t just throw up our hands in the air and abandon LWJGL when JOGL was “officially” announced by Sun.

Cas

[Varkas]

Inspuired by this thread I decided to set LWJGL up and see if I can get a small demo to run with it. Took about half an hour and worked without problems. I think this is a fairly good time for setting up a new framework, so I can recommend it at least from this point

Now on to make something serious with it …

Edit: Something makes me feel like saying “Thanks for the new toy!” … regardless if it fits this thread or not ;D

[matheus23]

@masteryoom

Isn’t JOGL the same as LWGJL except without the LWGJL code?(As in, the display). So, basically, the JOGL is like OpenGL, and LWGJL is that and extra? ???

@princec

JOGL is a bit like the OpenGL part of LWJGL, except it’s got the irritating requirement of passing round a redundant “gl” instance everywhere, which from the API perspective, is plain wrong, and why we didn’t just throw up our hands in the air and abandon LWJGL when JOGL was “officially” announced by Sun.

Cas

WHAAA?!?

Why people why???

Yes, JOGL is not that much of a library… It has “only” got NEWT, works also with AWT, and wraps Input and OpenGL… Then it also “only” adds utility classes for something like Framebuffers, VBO’s and includes a rendering loop and an FPS counter… (Let’s leave out the math utilities)

But yeah… Then there is also JogAmp, which is, what it should be called, and which is actually even another story…

I’m NOT comparing LWJGL with “JOGL”. I’m complaining about people thinking that “LWJGL” would be a “Game Engine” and JOGL being an “OpenGL wrapper”…
Neither of them is “only” an OpenGL wrapper nor a Game Engine!

And, NO PRINCEC, JOGL is NOT “like the OpenGL part of LWJGL”. It IS more.
And nope, nobody wants one to throw the hands in the air and abandon LWJGL.

I now get why people from JOGL get angry about such storys… :cranky:

[kappa]

@matheus23

And, NO PRINCEC, JOGL is NOT “like the OpenGL part of LWJGL”. It IS more.

Its not more its less, JOGL is just an OpenGL wrapper (with native windowing) LWJGL is a OpenGL, OpenAL and OpenCL, JInput wrapper (with native windowing). So technically you can say it is like the OpenGL part.

Oh and for clarification, Jogamp != JOGL but includes JOGL as a part.

[princec]

I stand by precisely what I have said.

Cas

[matheus23]

Yeah I understood what you said there now with it being the openGl part…

But it’s really not nice to do so, because these guys are talking about JogAmp actually, they just don’t know that that would be the right name for it.

Also, you should say “JOGL [like] is the OpenGL part of JogAmp” not LWJGL.

[princec]

I’m really not sure where the confusion arises. JOGL is JOGL and the question was about JOGL not JogAmp, and compared with “the OpenGL part” of LWJGL. And they are orthogonally equivalent give or take a couple of utilities and the aforementioned ghastly object-oriented hammer/nail paradigm.

Cas

[matheus23]

@princec

I’m really not sure where the confusion arises. JOGL is JOGL and the question was about JOGL not JogAmp, and compared with “the OpenGL part” of LWJGL. And they are orthogonally equivalent give or take a couple of utilities and the aforementioned ghastly object-oriented hammer/nail paradigm.

Cas

And in the end you didn’t even mention, that JOGL is not the whole story. That’d be nice.

The reader propably wouldn’t even know that you are actually not talking about the JogAmp project, which the reader propably thought JOGL would be, but JOGL.

So to the reader:

Yes, JOGL is only a OpenGL wrapper with a windowing system, called NEWT, which got input management, another windowing system based on AWT and a game loop.

But JOGL is only a part of JogAmp and JogAmp actually consists of:
[x] JOGL
[x] JOAL (OpenAL wrapper)
[x] JOCL (OpenCL wrapper)
[x] Many other utilities, like math utilities, some helpful classes for wrapping OpenGL stuff like, the Framebuffer or the VBO.

In the end I’d personally even say that JogAmp has much more “features” than LWJGL. You can argue about the GL instance and whether those features are redunant or not, but it seems to be a fact.

[princec]

I’m sure JogAmp has more features than LWJGL. LWJGL is not meant to have many features in it because those features are usually implemented in a way that someone else would like to do differently.

This being a forum full of programmers that program in a language that complains that This is not equal to this and you’re surprised that I give a very specific answer to a very specific question?

Cas

[matheus23]

The only problem I had was that it was misleading: You didn’t point out that JOGL is only a part of the JogAmp project.

Yes, the answer was very specific, but you should give more information, so the reader actually learns something.

[princec]

Didn’t really cross my mind to be honest.

Cas

[gouessej]

matheus23 is right, there is some helper classes to manipulate FBO, create textures, draw curves and texts directly on the GPU, simulate the fixed pipeline, display video, … JogAmp works fine on Raspberry Pi, it has been fully tested on lots of embedded devices, xranby can confirm that, it has an homogeneous support of OpenGL-ES. JogAmp is fully modular, you can deploy only what you need by using “atomic” JARs. All experts with whom I have worked find JogAmp very good and agree with our design choices, especially the interfaces (GL2, GL2GL3, …). You cannot compare JOGL with its competitor, it is more fair to compare it with JogAmp or to compare its OpenGL part with JOGL. Even JOGL is much more than a “simple” OpenGL wrapper.

The benchmark is flawed, just disable caching in the competitor of JOGL and you will probably get the same results. We advise to cache constants externally, like in Ardor3D (see JoglContextCapabilities).

[sproingie]

It’s 17 less keystrokes to type “LWJGL” instead of “The Competitor of JOGL”. I’ll add that the apparent maturity level of the developer community is a large consideration when choosing a platform.