Java for OpenGL API-Layer Discussion

OpenGL Development JOGL Development
#1

i open this thread to introduce a possible solution i’d like to see as a standard. this discussion is about the layer structure and the naming conventions in the different layers. my ideas might lead to a concept that is to far away from the current jogl design. if that should be the case please point me to another forum where such a structure could be discussed and set up.

the presented structure is not complete. it is a discussion-base.

i recommend an api layered in the following fashion, from bottom to top:


OpenGLCServer (called GL in jogl)
      static final public int GL_TEXTURE_2D 0xXXXX;
      static public void glVertex3i(int, int, int);
      static public void glVertex3f(float, float, float);
      static public void glVertex4f(float, float, float, float);
      ...

OpenGLServer
      static final public int TEXTURE_2D 0xXXXX;
      static public void vertex(int, int, int);
      static public void vertex(float, float, float);
      static public void vertex(float, float, float, float);
      ...

OpenGLContext
      public static OpenGLContext currentContext();
      public static void clearCurrentContext();
      public void makeCurrentContext();
      public void flushBuffer();
      public OpenGLDrawable drawable();
      public void clearDrawable();
      public void update();
      ...

interface OpenGLDrawable
      public OpenGLDrawable(); // constructor creates suitable OpenGLContext
      public OpenGLContext context(); // returns the context bound to this drawable
      public void display();
      ...

non-window-system-based drawables:
FullscreenOpenGLDrawable implements OpenGLDrawable
OffscreenOpenGLDrawable implements OpenGLDrawable
VirtualscreenOpenGLDrawable implements OpenGLDrawable

view/window-system-based drawables:
AWTOpenGLDrawable implements OpenGLDrawable
SwingOpenGLDrawable implements OpenGLDrawable
SWTOpenGLDrawable implements OpenGLDrawable

OpenGLCServer and OpenGLServer are identical in functionality, they only differ in syntax.
this specification would solve the following - already discussed - problems:

a) porting low-level opengl from c to java
OpenGLCServer wraps the underlying c-functions of OpenGL keeping the c-naming convention. this is a convenience class for c-programmers and other people wanting/having to stick to the c-naming scheme.

b) make opengl a good java citizen
OpenGLServer wraps the server by using method overloading. java programmers should use this interface for any new programs. this should be the recommended way to interface opengl with java. therefore it is not explicitly called OpenGLJavaServer.

c) automatic removal of unneeded pre- and postfixes with java 1.5
a static import of OpenGL©Server will remove the need to write


OpenGLCServer.glVertex3i(0,0,0); or
OpenGLServer.vertex(0,0,0);

and instead allow


glVertex3i(0,0,0); or
vertex(0,0,0);

d) partial independency of window-system
FullscreenOpenGLDrawable and OffscreenOpenGLDrawable should be independent of the underlying window-system (awt/swing/…). this opens the possibility of building apps that do not need to know anything about it.

e) exposure of the opengl context
the programmer is able to talk to the context whenever needed, not only in the draw-method. this allows for uploading/destroying textures, generating display-list, … at a choosen time.

caveats
the server-methods are kept static because opengl is a state-machine. the client itself has limited knowledge about the current active context. the programmer has to ensure that drawing is done to the right (current) context (or that the right context is current).
this becomes an issue when awt and swing are used.
the OpenGLContext has to be exposed to the programmer. otherwise the access to opengl would be to restrictive. the threading issues have to be adressed either by the programmer or by the awt/swing/… based classes.

OpenGLDrawables distinguish between the choosen output-path.
OpenGLContext is pretty near to NSOpenGLContext from apple.
input (keyboard, mouse) is not considered here.

your comments and ideas are welcome!

#2

Please see LWJGL.
As it happens I sit on the expert group for JSR231 (and 239 by proxy) and will shortly be presenting an overview of our API to the panel on matters such as this.

The key thing I have to say about discussions of this nature is: LWJGL has solved the abstraction completely, and in a manner which can support all the other abstractions - although LWJGL is deliberately incomplete (we don’t have any methods that take doubles for example as these aren’t relevant for consumer-class hardware and games).

The other key thing to say is that it works perfectly and it’s here today, except it needs a bit of help with Mac Windowed/Fullscreen support and I think you might be the one to fix that :slight_smile:

Cas :slight_smile:

#3

Nice.
I have to say the use of term “Server” in any Java lib is going to be confusing, even though this is what OpenGL calls this.

This really shows the difference between what the game community would like to see in Java OpenGL wrappers and what the JCP expert group sees (see JOGL).

Good luck!

#4

Note that the gaming community is only a small portion of then total users for OpenGL bindings. Those of us in non-gaming land don’t want abstractions or anything that gets in the way of creating high performance code that runs on something other than a PC. I disagree very strongly that LWJGL is the “right” answer for anything involving Java bindings to OpenGL as it hides way too much of OpenGL from the end user to make it useful for anything other than simple games.

#5

LWJGL hides nothing from the end user except doubles (which are a red herring on all consumer class hardware) and methods which were designed for performance in C such as glVertex3fv which are actually vastly slower in Java. I’m not sure what you’re saying here.

Cas :slight_smile:

#6

I don’t want to go in a big debate, but I think that Mithrandir is right saying that JOGL is not only meant for games…

I you want to make a binding to openGl you may want to only offer underlying API, even if some parts of it are very slow…
It’s up to the user to choose if this is sufficient or if he(she) should turn to another library.

Maybe LWJGL is better for some applications and JOGL for others, and maybe one of them is the best for all. But I think their purposes are not the same and …, well keep them both alive will certainly be a good solution. no? ???

#7

LWJGL is certainly not only for games either, we’ve just made it especially easy to write games using it by bundling a few bits and bobs in with the binding like a simple windowing context, OpenAL and some trivial input APIs.

The API layer discussion alluded to here has particular reference to the fact that GL is a static library - and it’s implemented as such in LWJGL (which makes it possible to implement JOGL in terms of LWJGL…) As for naming conventions, we went with the defacto C standard and aimed directly at JDK1.5’s static import feature although where the actual method signatures differed, mainly as a result of using Buffers instead of pointers or arrays, we have stripped superfluous suffixes to avoid confusion. atze stated in his opening paragraph that he might well be deviating totally from the JOGL design and needed redirecting to a forum where his ideas are already in practice :slight_smile:

bootnote: LWJGL was actually originally developed for - and is still in use by - television graphics systems. It’s fully integrated with SWT now, and it’s fully compatible with JOGL-created contexts. It comes with GL interfaces and a standard implementor, as does JOGL. It would be nice to get a build of JOGL that did nothing except create contexts (ie. no binding) because we could then just simply use LWJGL with AWT.

Cas :slight_smile:

#8

[quote]LWJGL hides nothing from the end user except doubles
[/quote]
Which makes it very gaming centric. There’s nothing wrong with that. It’s just it’s no generic binding then.

#9

On the surface it would appear to be gaming centric but seeing as all the drivers simply convert doubles back down to floats again before anything happens to them it’s neither here nor there… you can still implement JOGL in terms of LWJGL - the conversion will merely be done by the Java VM instead of the OpenGL drivers thus:


public void glVertex3d(double x, double y, double z) {
glVertex3f((float)x, (float)y, (float)z);
}

…feel free to add the double methods back in some extension classes :wink: I might add them myself in the LWJGL util package.

Cas :slight_smile:

#10

This is what I was talking about BTW, not that it was “gaming” centric or something and that was limiting. I meant that it exposed OpenGL closer to the REAL OpenGL. JOGL hides the context from the user, and this so far has created interesting solution paths for wrapping OpenGL to say the least.
JOGL “softens” OpenGL and protects Java porgrammers. When I refer to gamers I simply mean they aren’t asking for that protection, they want direct(X) control. :wink:

#11

hm… no real discussion about my topic.

anyway, my problem with any unreachable (read ‘private to the framework’ stuff (context in jogl) is that i always and in every system i’ve used i had to break the lock after i understood the system. otherwise i’d be forced to find another system to work with.

so either i can drill down to a usable context whenever i need it in jogl (try to unload a texture in the draw-method if the object holding the texture is already gc’ed sometime before the draw-call), or i have to find a system that suits my needs better.

i’m currently checking lwjgl. i finaly managed to compile it but i can not get any demo to run. that leaves a bad taste and i have no time to dig deeper into the system.

you can not differenciate a system by saying that it’s for game-programmers or for a ‘professional’. the difference is only if it is an open or a closed system. closed systems are of no use for anyone than a beginner. such systems are toys (no offense) to play around but not to get the work done the way you want it. (why is elementData in Vector protected? why is String final? there are things in java that i don’t like either) :wink:

what i need is a clean opengl-binding with no additional restrictions that i don’t have if i’d use C instead of java.

and if multithreading seems to be a problem to some then don’t use awt or whatever might get in your way. or just learn the concepts of multithreading and build the restrictions you want yourself.

could we please get this discussion back to the point? thanx a lot!

#12

[quote] The API layer discussion alluded to here has particular reference to the fact that GL is a static library - and it’s implemented as such in LWJGL (which makes it possible to implement JOGL in terms of LWJGL…)
[/quote]
And thus making it completely useless for implementing large-scale or multiscreen displays where you have multiple rendering contexts running in parallel. When first evaluating code for implementing Aviatrix in, that was the first thing I did - wrote a dual screen, multi-threaded rendering test. LWJGL fell over before even getting something on screen due to the thread clashes. JOGL at least can handle that, same as GL4Java. That’s the difference between gaming-oriented designs and generic designs - they don’t make any assumptions about the user’s system. Anything that starts with a static context to do drawing with will fail miserablly in a multi-threaded + multi-CPU system, which is our typical bread and butter application development scenario.

[quote]LWJGL hides nothing from the end user except doubles (which are a red herring on all consumer class hardware)
[/quote]
And therein lies your problems with acceptance of LWJGL. There are many of us not working on desktop PC applications. It’s precisely these sorts of assumptions that make it an unworkable solution for the non-gaming market.

[quote] anyway, my problem with any unreachable (read ‘private to the framework’ stuff (context in jogl) is that i always and in every system i’ve used i had to break the lock after i understood the system. otherwise i’d be forced to find another system to work with.
[/quote]
As such, you’ve chosen the wrong language and libraries to develop with. The point of Java is a level of abstraction over the system. The fact that you’ve felt “compelled’” to break the abstraction smacks of NIH syndrome and/or lack of imaginative thinking. By your definition, everything, even assembler, is an abstraction and they get in the way, so you should be coding in raw machine code.

As far as the existing JOGL code is concerned, we’ve been able to get it running on almost everything we’ve tried (particularly after they finally allowed explicit swapBuffer() calls). The only times we’ve failed to have JOGL-based code run where C code would is when we needed explicit genlock capabilities. Add to that, that in our application space, we’re already getting at least twice the framerates of all our competitiors really doesn’t hint much at lacking capabilities or where traditional C/C++ techniques are concerned, that we’ve found more than acceptable alternate ways of doing it. Most of the time, thinking outside the box is going to be far more beneficial than thinking inside of it.

[quote] you can not differenciate a system by saying that it’s for game-programmers or for a ‘professional’.
[/quote]
How much professional 3D graphics development have you done? By that statement, I would say - not much.

How many CAD applications do you see written in DirectX? How many CAVEs or Powerwalls do you see running DirectX applications (or even just Win32 machines)? Take an advanced shader written in GLSLang and then convert it to HLSL and see how much capability is missing.

So all those commerical J2EE application servers are no more than beginner toys, or Win32 for that matter. That’s a really bad argument to use for separating what a beginner system is and is not.

[quote]what i need is a clean opengl-binding with no additional restrictions that i don’t have if i’d use C instead of java.
[/quote]
That’s just not going to ever happen. The whole JVM thing imposes a lot of restrictions on the way applications work. Pointers impose a lot of different application load that just can’t be handled in Java (particularly void*).

If you really feel that restricted by the JOGL APIs already, then I think you’ll always have problems. Since we’ve been able to implement almost every type of existing native-OpenGL style application using JOGL already (with the above exception already noted), I really can’t see any major issues with the existing design philosophy.

#13

Mithrandir, you are going off on one a bit here. This guy is talking about a design philosophy for a binding. LWJGL meets the style that he would like; if effectively lets him work in the same way as C would.

The exact implementation of the design philosophy might not be to your needs in CAD/CAM but there is nothing stopping anyone from simply putting double methods directly back into a fork of LWJGL for CAD/CAM - which might solve your issues with the library but have nothing to do with antze’s discusion.

Furthermore wrt. multithreading, LWJGL is exactly as multithreaded as JOGL is. That is to say, not multithreaded; JOGL is not a multithreaded binding - it’s a static binding with a feeble veneer of object instantiation over it, which entirely disguises the fact that GL context are thread-local hardware contexts, and the concept simply does not work either in usefully reusable library terms or in expected functionality terms. JOGL comes with some conveniences for the AWT programmer to create multiple contexts and you can indeed use these contexts in vanilla form with the LWJGL binding if you so desire. All the multithreadedness is in the JOGL context management. There is no requirement to use the LWJGL-created Display context (which bloats our distribution by approximately 20kb).

We supply a JOGL-style GL interface and default implementation of that interface which, if nothing else, merely underlines the fallacy of the OOP model used. It’s a bodge to cover a hole in Java’s capabilities. But at least one can do daft things like subclass it and put debugging on GL methods if one feels so inclined.

Therefore it is purely a matter of antze choosing what kind of context management he wishes to use and using the appropriate library; and then choosing the style of binding which he wishes to use and using the appropriate library.

gregorypierce in the end gave up on the lot, and created his own context creation and his own (LWJGL-style) binding.

But the discussion really doesn’t have anything to do with CAD/CAM, and really, being a gaming board, it shouldn’t have to. JOGL was hoisted into a position as the flag-bearer for Java gaming technology (and it would seem that while it’s sat there showing off its too-white teeth and shiny medals, the little soldier LWJGL is out there actually producing real, working, deployed games and applications). Make of that what you will.

Am I ranting here?

I’m beginning to sound like blah^3!

Cas :slight_smile:

#14

Raw bindings to the ‘C’ openGL APIs shoudl be done once, in one library/class. Never to be done again accept to add bindings to new OpenGL APIs and features.

Then all the context management, threading crap, auto swapbuffer stuff, etc… should be written on top of that binding. Each machine likely has only one (useful) native OpenGL library… therefore there only needs to be bindings that expose it, all of it, at the rawest possible level. Then you can build all sorts fo wonderful things, purely in Java with no need for more native code (most of the time?).

The low-level GL bindings should implement an ‘official’ OpenGL “interface”, should a ‘light’ version be made with now access to methods taking doubles for example, those methods could throw a NotImplemented exception or some such thing, while the float methods work as always.

Does that seem reasonable, or am I talking out of my *ss? (I haven’t written any OpenGL code yet myself, so I really should just stay out of it :slight_smile: )

#15

It’s a can of worms. Not least because of the requirements to support subsets of OpenGL for certain platforms (eg. consoles, J2ME, OpenGL ES) and certain application spaces. If what you’re after is a single standard binary JAR deployment with a platform specific DLL, a standard binding implementation is guaranteed to fall over in some unexpected place if you try to please all of the people, all of the time.

Also supporting everything raw isn’t quite so straightforward as it looks - there are all sorts of platform specific oddness to deal with like HWNDs and HDCs and HGLRCs - and exposing them to Java programmers is probably not going to be fun. On the other hand exposing them in a “private” API for the use of a “public” API has some mileage, a la SWT. SWT’s design is quite nice in that it absolutely puts everything in Java-land but this allows Java developers to access things directly - and programmers being programmers they’ll start coding down to specific platforms and then when it doesn’t run everywhere there will be the usual round of sarcastic C++ types crowing “write once debug everywhere, yeah right”. And of course you’re then down to deploying “fat binary” JARs or deploying a different JAR implementing the same interface for each platform which just seems messy for what, at the end of the day, is just a totally trivial piece of bloody code in the first place.

Cas :slight_smile:

#16

[quote]Raw bindings to the ‘C’ openGL APIs shoudl be done once, in one library/class. Never to be done again accept to add bindings to new OpenGL APIs and features.
[/quote]
yes, that’s exactly what i’m looking for!

[quote]… the requirements to support subsets of OpenGL for certain platforms
[/quote]
just implement the base standard as an interface. then add the platform/hardware specific methods in a concrete implementation. make that implementation a public class, so that the programmer can decide to stick to the interface (runs on all platforms) or use the native machine-dependent class explicitly (read: has to cast to platform-dependent class) where available.
and there still is GLboolean glIsEnabled(GLenum capability) to avoid falling into a pit.

so is anyone able to come up with such an interface and do an implementation-skeleton that we could just flesh out on the different platforms?
and maybe the interface could have an identifier (String/array) that could tell the programmer what platform-specific extensions are available?

on top of that you could then put any awt/swing/swt/fullscreen/offscreen/… implementation you like.

#17

LWJGL does this. Calling org.lwjgl.opengl.GLContext.useContext(context) will automatically enable or disable all extensions available to that context. We have most of the useful ARB and EXT extensions, and the NV and ATI ones and a few miscellaneous bits and bobs.

Cas :slight_smile:

#18

[quote]Mithrandir, you are going off on one a bit here. This guy is talking about a design philosophy for a binding. LWJGL meets the style that he would like; if effectively lets him work in the same way as C would.
[/quote]
Exactly. And I’m refuting that these are good design philosophies to follow for any OpenGL binding in Java. In fact, I’m pointing out that they are going to cause more long term pain than good. On the other side, I’m pointing out that the JOGL level of abstraction is “about right”, in that it achieves the level of balance needed to have a functional OpenGL binding that is also portable from O/S to O/S. As for dealing with the rest of the points originally brought up by Atze, I’ll do that at the end of the post.

[quote] Furthermore wrt. multithreading, LWJGL is exactly as multithreaded as JOGL is. That is to say, not multithreaded; JOGL is not a multithreaded binding - it’s a static binding with a feeble veneer of object instantiation over it, which entirely disguises the fact that GL context are thread-local hardware contexts, and the concept simply does not work either in usefully reusable library terms or in expected functionality terms.
[/quote]
And that is where you and Atze are fundamentally wrong. It’s either because you’re niave about the way users develop Java applications and the way the JVM is specified, or just have no experience developing really large scale or realtime applications.

Starting with the first fundamental design flaw: The use of globally static objects in Java design. Simply put, anything that requires large-scale state awareness should never be put into a static object. A static object is not global. It is local to the classloader that it was loaded from. That means the implicit assumption that both LWJGL and Atze’s proposal are based on (“there is only ever one OpenGL server per machine”) is wrong and cannot be mapped to the Java concept of a static class (also, what if your app is wanting to talk to two different servers on two different displays ala - X-windows $DISPLAY settings?). Static classes also have issues dealing with a lot of different users all interacting with them at once. You only have to look at the problems with syncrhonised method or blocks of code acting in a static class that you’ll see a great illustration of this issue. Good Java design philosophy keeps static objects and classes to an absolute minimum - typically good for factory objects and simple utility classes that have no state kept between method calls.

The openGL drivers are thread aware and make use of the local thread context to know which part of the screen they are drawing to and which context they should be using (that’s what makeCurrent() does). Now, what happens with the Java thread that you’re in doesn’t equate to an underlying O/S thread. Say the JVM implements green threads (almost guaranteed on any small footprint device), or the coder is using one of the third-party threading libraries? When your Java code calls makeCurrent() what does that mean? As far as the OpenGL driver is concerned, there is only ever one thread that you’re working with, but your application level code is drawing to two, or more different windows or other operations. Or, looking at it from another way - if you’re using a supposedly global static variable to represent the server, how is that server going to work out which context you’re drawing to when you can’t determine which thread is actually doing the requests?

Either way you look at it - from the Java side or from the OpenGL side, static interfaces and representations of the OpenGL contexts cannot work in all but the most simple of environments. Try to do something non-trivial, and it will fall over in a big screaming heap.

[quote]Raw bindings to the ‘C’ openGL APIs should be done once, in one library/class. Never to be done again accept to add bindings to new OpenGL APIs and features.
[/quote]
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.

As for what we’d like to see - Everything is fairly good at the moment. We’d certainly like to see the APIs pushed a little lower in the abstraction. The genlock example of one of my earlier posts is on such issue. Would we like to have makeCurrent() available? It would make some things a little more easy to implement, but since we can do everything as the code exists already, there’s no great burning desire. Instead of spaghetti code littered with makeCurrent() calls all over the place, just push the information down to your canvas rendering loop and deal with it all there. There’s nothing that difficult about it and it’s trivial to do. These are the sorts of things where the “but I have to do it this way and the API is broken because I can’t do it” arguments are completely baseless. If a developer can’t think of even that slightly different design, you bet I’m going to question their abilities.

Now, dealing with Atze’s original post. Most of those are not worth talking about as they’ve been covered so many times that it’s pointless going back to them. Prefix/suffix stuff, has already been decided by the JSR expert group. Layered APIs issue has already been decided, exposure of the native window stuff as well. That leaves the one and only interesting issue left - that of the static class representation. That’s what I’ve been addressing here.

As for the comment of “JOGL is games only” you really need to get a reality check on that. The only reason it’s here is because there is nowhere else on Sun’s place to put it. Java.net is a global community area for all sorts of Sun projects. Most of them don’t have forums for discussion, so it is more of a convenience than anything else to put it here. For one, as a large-scale user of JOGL, where else can we go to discuss issues, bugs etc associated with it? It’s not like there’s a dozen different JOGL forums floating around on the net. So, don’t get too cocky about non-game developers being in here and telling us to go away and mind our own business. 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.

Since Atze came into the JOGL forum and started a thread on java-opengl bindings in this forum, why should we assume that he is not talking about his design preference for JOGL? If it was meant to be a generic question of “where can I find this style binding” then there are a couple of other places on this forum to make such a post. In fact, his first sentence is “a possible solution to see as a standard”.

#19

!

Cas :slight_smile:

#20

"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?

I really would have to believe that there are more OpenGL games in existance AND in use than any other type of OpenGL app, but I could be wrong, where are you getting your numbers?
(OpenGL may have been developed by sim graphics companys, but gaming ownZ U now! ;D)

And in any case, it is exactly that kind of statement that alienates the “serious important openGL developer” from the “goofy toy OpenGL game developer” (sarcasm alert)

Personally, I have worked with enough sim/training-types and their self-important attitude (as demostrated above) when addressing game tech that I pretty much just leave them alone. Which I will also do now again.