LWJGL Static Methods

[Illuvian]

I'm new to LWJGL. I've done some Java allready and have worked with JOGL a little bit. I got this one question about LWJGL. Why are all methods static ?
In JOGl, they aren't, you first use Gl gl =  getAutoDrawable.getGL() or something like that. After that, you use gl.glVertex3f() for example.

[numberR]

i think the one of reasons why all gl functions are static is for performance.
another reason, i think, is how OpenGL is designed.
OpenGL is so structured and not object-oriented, it fits with static methods in Java.

cool thing about jogl, even though i'm not super familiar with it, is that it wraps all gl functions to object so we can take object-oriented approach (passing GL object for example).
it's also good that it encapsulates OpenGL context, so you can switch OpenGL contexts depending up on which GL object to invoke gl functions on (i could be wrong here due to lack of knowledge of jogl).

[Illuvian]

So actually, JOGL fits more with Java than LWJGL ?

[Matzon]

OpenGL is a c library, that is no classes, only functions and structs.
LWJLG's OpenGL implementation just mimmics this behaviour so you will be able to do:
import static org.lwjgl.opengl.GL11.*
and then write code that looks mostly like its c counterpart.
We also have an GL object if you *really* have to in org.lwjgl.util.GL

I'm not sure whether jogl actually has any context management in regards to having two contexts, I am fairly sure that you still have to make one of them current?

[aldacron]

So actually, JOGL fits more with Java than LWJGL ?

What does that mean? Java allows static methods, yes? They are just two different design methodologies. Neither "fits" with Java more than the other.

That said, JOGL allows you to swap GL implementation instances, since GL is actually an interface there. There's a DebugGL that you can use in place of the default. Also, IIRC, because of JOGL's original architecture it was important to fetch the GL instance each time through the render loop (much as getGraphics is used in Java2D). I don't know if that has changed with the implementation of JSR-231. JOGL does support multiple contexts, with each GL instance representing a context.

The only difference between the two implementations is that LWJGL doesn't allow you to swap out another GL instance. That's not needed for debugging since you can turn it on and off via a property in LWJGL. So it's a case of supporting a feature that is rarely used while making everyone pay for the overhead (granted, it's not much, but there is more overhead calling methods on interface implementations than static methods) or not paying overhead for it and disallowing it altogether.

[darkprophet]

If anything, swapping GL instances is actually harder IMHO.

Ive played with both, and its just a nightmare pushing two instances around, 1 is hard enough.

A simple call to Display.makeCurrent(); (assuming the other thread has released the context) is much cleaner and easier to work with and debug.

But thats my opinion ofcourse, you have teams on both ends.

DP

[appel]

Another explanation

OpenGL is a state-machine. It changes state depending on what commands you give it.

I don't know how JOGL works, but I'm pretty sure it doesn't do anything more than just sugar-coating the OpenGL's state-machine. I'm pretty sure if you dig deeper into JOGL you'll see that it functions similary as LWJGL.

LWJGL = If you want to cook the dinner yourself
JOGL = If you want to  go to a restaurant and have the same dinner

[oNyx]

So actually, JOGL fits more with Java than LWJGL ?

So Math with all its static methods doesn't fit Java?