Java for OpenGL API-Layer Discussion

[nnevatie]

[quote]"There are orders of magnitude more non-game users of OpenGL than gaming. It certainly doesn’t help gain any favours with that sort of attitude. "

Can you back that statement up?
[/quote]
Boys, girls! When there’s a fight, there’s google-fight!

query results for “opengl game” (without the quotes): 367 000

query results for “opengl application” (without the quotes): 290 000

The winner is OpenGL games! But only with a slight margin! The second is OpenGL applications! Congratulations to all those who participated!

Sarcasm aside, it is clear that there is need for non-gaming OpenGL, especially with Java. There’s also need for “hybrid” applications: editors for games that require a decent user interface (Swing/AWT/SWT; sidenote: princec, as I know you scan all these messages through in hope of having an opportunity to magically pop-up and present us salvation via LWJGL, I’d like to remind you that there’s no such UI integration in place in LWJGL…and, no it does not pollute your cvs to have an UI implementation to offer as an extension to your low level graphics library ;)).

It’s kind of sad to see the the innovative potential wasted because of the endless NIH syndrome of smart people. Instead of having five separate OpenGL bindings for Java, I’d like to see one that works (princec, try to contain yourself :)), and not just for games, but for windowed applications as well.

[princec]

…can’t…help…posting…!

The great thing about philosophical arguments is that one of their defining characteristics is that it is impossible to know the answer.

Like I say, we’ve got LWJGL integration with AWT and SWT already via adaptors - JOGL being one. And that’s all that need be said.

Cas

[swpalmer]

As Cas started to point out, this is the worse thing you could do for a Java binding. Think of how you start code in a native application - you have to use some sort of windowing-specific toolkit to get you started, establish GLContexts, select windows etc. That means that Java code would now have to work out which platform it was running on and make use of the appropriate GLX/WGL/AGL interface to determine what is going on. That’s the complete opposite of what Java does in it’s libraries.

Whoa…
That is not at all going in the direction that I’m thinking. The JRE is already platform specific. It’s not like we download one set of Java parts that work on everything, and then ONLY a VM that is specific to the platform.

Or have you not noticed all the packages that mention win32 in the name when looking at a stack trace on Windows?

MY point is quite simple: There generally are NOT multiple OpenGL APIs at the native level on each platform. If there is a single OpenGL API on the platform then there need only be a single binding to those native methods.
All of the other funky platform specific bits that Cas has mentioned and you are mentioning would be easier to implement in Java would they not? (Perhaps more than JUST OpenGL APIs will need bindings if interaction with window managers or some such thing is needed)

Does that not offer the most flexibility? Can you not implement JOGL and LWJGL and such on top of very basic RAW bindings such that the native code is minimized?

Note that I’m not talking games versus other apps, or single display versus fancy 3D caves… I’m simply saying that a simple function in the OpenGL API doesn’t need to have a zillion different native bindings that are all exactly the same - but are used by different Java APIs like JOGL or LWJGL. When JOGL calls method gl_BLAH and LWJGL calls gl_BLAH they must use the same method signature … why do they each need their own binding to that method?

[nnevatie]

I’m simply saying that a simple function in the OpenGL API doesn’t need to have a zillion different native bindings that are all exactly the same - but are used by different Java APIs like JOGL or LWJGL. When JOGL calls method gl_BLAH and LWJGL calls gl_BLAH they must use the same method signature … why do they each need their own binding to that method?

My point exactly. All Java OpenGL bindings unite!

[princec]

We cannot unite - there are philosophical differences between our API styles. And as I say, the important defining characterics of philosophy are that no-one knows the right answer because there may or may not be one, so arguments are always endless.

Cas

[nonnus29]

[quote]Try to do something non-trivial, and it will fall over in a big screaming heap.
[/quote]
This made me think; ‘what would be a non-trivial opengl app?’. I’ve seen a military simulator with about 6 displays per unit and about 50 units; it was a battalion level tank simulation (we called it simnet that doesn’t google though) and it ran on minicomputers in a big warehouse. I wasn’t in a position to ask alot of questions at the time though.

Edit Here’s a link.

[kbr]

I’m coming to this discussion a bit late but I feel compelled to comment on this:

MY point is quite simple: There generally are NOT multiple OpenGL APIs at the native level on each platform. If there is a single OpenGL API on the platform then there need only be a single binding to those native methods.
All of the other funky platform specific bits that Cas has mentioned and you are mentioning would be easier to implement in Java would they not? (Perhaps more than JUST OpenGL APIs will need bindings if interaction with window managers or some such thing is needed)

Does that not offer the most flexibility? Can you not implement JOGL and LWJGL and such on top of very basic RAW bindings such that the native code is minimized?

JOGL is implemented in exactly this fashion, and is similar to the SWT’s implementation in this regard. All of the low-level window system APIs, including the JAWT, are first bound into Java using the GlueGen tool, and the rest of the package is written in (platform-specific) Java. There are only 50 lines of handwritten native code in JOGL; the rest is Java.

Different OpenGL contexts may have different entry points, at least on the Windows platform. JOGL makes this explicit, even in its implementation, so in at least some situations the “low-level” or “raw” OpenGL binding requires more of the JOGL-style infrastructure than simply the binding to the native methods.

You might find the implementation of classes such as JOGL’s WindowsOnscreenGLContext interesting.