This class is thread-safe in the sense that multiple threads can safely call all public methods. The class is also thread-aware in the sense that it tracks a per-thread current context (including capabilities and function pointers). That way, multiple threads can have multiple contexts current and render to them concurrently.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I like the fact that LWJGL is a 1-1 binding to the native OpenGL API. I do like first-class object-oriented graphics contexts, and think they're a better way to think about a lot of the stateful bits, but that's something a pure java layer could do without much additional overhead.

Ultimately it doesn't make a hell of a lot of difference in the end, you still have to deal with the awesomely crufty and awkward API that is OpenGL either way.

It beggars belief how people can so thoroughly misunderstand OpenGL context management, still, after all these years. Though I suppose some people were about 6 years old when we first made LWJGL. One born every minute and all that.

As soon as I know, they plan to fix this design flaw in the third version.

It wasn't a design flaw, it was a design choice to keep the native window implementation simple. Multiple contexts have been supported for a long time through AWT. A lot of things will obviously change in the next major release, but the current architecture has worked pretty well for a lot of people.

"all static" drives it simple/simplistic which is nice for newbies but it has a cost.

What cost is that exactly? With JogAmp you need to pass GL instances around, 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.

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

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.

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.

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

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.

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.

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.

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:

JOGL

JOAL (OpenAL wrapper)

JOCL (OpenCL wrapper)

Many other utilities, like math utilities, some helpful classes for wrapping OpenGL stuff like, the Framebuffer or the VBO.

[size=8pt]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.[/size]

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

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