jogl API feedback requested for JSR 231

[shaddam_IV]

It is my opinion that the “objectification” of the state machine in the GLDrawable is a great way to leverage the best of both OpenGL and Java. It would be a major mistake to drop the gl.glFoo() and revert to glFoo() (where gl is a GLDrawable).

The beauty of having a GLDrawable is that each state machine/context is associated with a single GLDrawable. This means you don’t have to worry about keeping track of which RC you are currently using. The one associated with your GLDrawable is it.

BTW/OT, when the spec drops the GL_ from a function, that is merely for convenience. The actual enumeration always has the GL_. Don’t even think of dropping the GL_ prefix.

[shaddam_IV]

[quote][issue] that seem[s] to keep coming up:

1. Use of the gl contexts outside of the display() method. I’m not proposing any course of action, but this seems to keep surfacing as an issue in code in the forum
   [/quote]
   It is my personal opinion that rendering should only occur in rendering functions. This goes along with the idea of modular design. This means that there is no reason to have access to the GLDrawable in, say, a simulation function. In any event, you can certainly hack the class and get access to the GLDrawable in other locations than in display.

[shaddam_IV]

My inputs:

[*]Definitely keep the whole GLDrawable setup. This is a great way to leverage the OOP design of Java with OpenGL.

[*]Get rid of GLJPanel. I am developing a cross platform PC & Mac Swing app that uses GLCanvas. These technologies play together just fine. There are a few caveats with popups, but they are no big deal. The existence of GLJPanel perpetrates the myth that you should never use GLCanvas with Swing, which is bogus.

[*]I think that the ability to create pbuffers should be available without the requirement to derive them from a viewable GLDrawable. They should also not be lazily created. AFAIK, I can create an offscreen RC in a C/C++ program without having to create an onscreen one. Why not the ability to do the same in JOGL?

[*]There should definitely be a user controlled swapbuffer command in the form of gl.glSwapBuffers() or something like that.

[*]I would eliminate the Animator class and instead provide a nice tutorial on thread safety and OpenGL. I don’t think it should be that hard to manage things so that all of your rendering goes on in one thread. After reading the simple Animator source, I understood things a lot better. it would be a good thing if the Java GL developers understood what was going on under the hood.

[*]Make the bindings a standard part of Java 1.x (x>.5). Java2D is part of the core, so why aren’t the gl bindings?

[*]Rename the package to javax.media.opengl, as the JSR suggests. Not everyone is using this library for games.

[*]Make resources shareable across contexts. You can do this on most other platforms via calls such as wglShareLists. Of course, this would have to be abstracted away to something like joglShareLists.

[mithrandir]

Just to chip in on the gl prefix. I think it should stay there. Makes comparing C/C++ to the Java version very easy and consistent. For example, you’re scanning a heap of code and you come across “vertex3f()” Now what does that mean based on a 20ms instant recognition thing? Are we working with the vecmath package, OGL calls or something else?

Also, one issue to factor in will be static imports in JDK 1.5. A lot of those GL.GL_foo things will disappear and you can go to using GL_foo saving plenty of typing.

As for the rest, I’ll add more comments tomorrow after I’ve played with it to see what has changed. In general, I want a real specification. One that actually specifies behaviour, not an API declaration like Java3D has. Try doing anything in realtime with dynamically created pBuffers and you’ll see what I mean.

[GKW]

[quote]Get rid of GLJPanel. I am developing a cross platform PC & Mac Swing app that uses GLCanvas. These technologies play together just fine. There are a few caveats with popups, but they are no big deal. The existence of GLJPanel perpetrates the myth that you should never use GLCanvas with Swing, which is bogus.
[/quote]
Considering GLJPanels performance right now I don’t htink many people are going to use it anyway. But in the future I think it will be a good thing to have around.

I think that the ability to create pbuffers should be available without the requirement to derive them from a viewable GLDrawable. They should also not be lazily created. AFAIK, I can create an offscreen RC in a C/C++ program without having to create an onscreen one. Why not the ability to do the same in JOGL?

I looked into this and you need to create a onscreen window, you don’t have to show it though, to create a pbuffer with Windows. I wouldn’t mind removing the lazy instantiation but you would only be able to create a new pbuffer in one of the GLDrawabel methods.

[abies]

[quote] For example, you’re scanning a heap of code and you come across “vertex3f()” Now what does that mean based on a 20ms instant recognition thing?
[/quote]
No, you won’t see vertex3f(). You will see gl.Vertex3f() as opposed to gl.glVertex3f(). But I understand that having to keep method starting with lower case is top priority, and gl.vertex3f is indeed too different from current standard.

[blahblahblahh]

No, you won’t see vertex3f(). You will see gl.Vertex3f() as opposed to gl.glVertex3f(). But I understand that having to keep method starting with lower case is top priority, and gl.vertex3f is indeed too different from current standard.

You cannot really answer this issue without defining the audience.

Audience: OpenGL newbies relying on word-for-word source-code compatibility between NeHe and java, who are too thick or lazy to read documentation and apply a simple transformation

– Keep as is

Audience: OpenGL C programmers who want to not have to open their brain for a little while to use a cleaner, simpler, interface definition.

–Keep as is

Audience: OpenGL C programmers who want to translate / port source

–Don’t care either way, so long as a simple regex will convert from one to the other. In fact, if the regex’s were provided by someone else, they’d be deliriously happy

Audience: Java programmers coming to OpenGL

–Remove as much of the cruft as possible, since it gets in the way of “thinking in java” and it marginally reduces productivity. It is also stressful and painful, largely because the programmer is aware it’s unnecessary [sad, but true: if you know you’re doing something you don’t like AND THERE’S NO REASON YOU HAVE TO, it makes it extra undesirable] (seriously: these are primary reasons why I’d never accept a C contract ever ever again: it’s just too painful to keep making up for shortcomings in the tools by inserting additional programmer effort)

Audience: Java programmers making extensive use of fancy IDE’s with autocomplete

–Remove as much identical prefix as possible, within the bounds of whatever the audience wants otherwise, since “GL.GL_something” MORE THAN DOUBLES the amount of typing for most vars, ditto “gl.glSomething” - they turn “2-3 keystrokes for tolerably small match-set” into “7-8 keystrokes for tolerably small match-set”.

Personally, as someone who is glad to have escaped “thinking in C”, and has had (on occasion) to go back to C programming for short periods, I wouldn’t be happy with anything more than:

gl.vertex( … );

Anything else insults my intelligence and makes all the OpenGL source code psychologically incompatible with the rest of the game - I hate the additional effort of having to “context-switch” your brain into this crappy “ultra-hardcore-polish-notation” which was only invented to work around a crappy 2-bit programming language design.

With about half of devlopers appearing to dislike/hate 2-character or more polish notation, why is it that people here want to force at least 2 and often much more on every programmer?

Note: I’m only describing how I feel, and I’m not claiming it should be done to satisfy me; as I said, I think you should make the decision based on an evaluation of your intended audience first and foremost.

[kaffiene]

I striongly oppose the idea of changing the prefixes. The biggest issues doing OpenGL in Java are purely OpenGL issues and being able to communicate with the OpenGL world is a really handy feature of the current naming scheme. I have posted my jogl java code to openGL news groups and C programmers have had no problem understanding the code.

That is a good thing.

If we want to encourage programmers in the C/C++ world to use Java, it is doubly a good thing to leave things the way they are.

Also, it would break everyone’s code to change it now.

I really like the fact that there is very little diffrence between my Java OpenGL code and my C++ OpenGL code. I think this benifits newbies as well as old OGL hands since the vast body of OGL code out there can work fairly much directly.

[pepijnve]

I second blahblahblahh’s opinion on the prefix issue. It really depends on what you’re going for: a direct port of the C implementation of the OpenGL spec or a Java implementation of the OpenGL spec. Personally I don’t see any benefit in having

gl.glVertex

over

gl.vertex

besides the capitalization issue of the first character.
I’m also fairly sure that any decent c/c++ programmer can understand both versions…

[abies]

[quote]I striongly oppose the idea of changing the prefixes. The biggest issues doing OpenGL in Java are purely OpenGL issues and being able to communicate with the OpenGL world is a really handy feature of the current naming scheme. I have posted my jogl java code to openGL news groups and C programmers have had no problem understanding the code.
[/quote]
So you claim that they are able to understand
gl.glEnable(GL.GL_TRIANGLE)
and would not be able to understand
gl.Enable(GL.TRIANGLE) ?

[TheBohemian]

What about some testing time:
Wrapper classes for GL (the current one with prefixes like in C) and GLU (!) could be which contains only java-conforming names. Constants should be redefined as well.

Then let us use and evaluate this for some time and see whether it is nice or bad.

[shawnkendall]

[quote]… The biggest issues doing OpenGL in Java are purely OpenGL issues and being able to communicate with the OpenGL world is a really handy feature of the current naming scheme. I have posted my jogl java code to openGL news groups and C programmers have had no problem understanding the code.

That is a good thing.

If we want to encourage programmers in the C/C++ world to use Java, it is doubly a good thing to leave things the way they are.
[/quote]
This says it all.

[shaddam_IV]

Please forgive the somewhat OT post here, but I can’t resist.

You cannot really answer this issue without defining the audience. . . .

In support of the above author and those with similar leanings, I propose a new JSR named “Break the standard in favor of fewer keys and obfuscated code for lazy programmers API”. Logically, the number would be JSR 7, since 7 is only one key and is easily reachable from my strong right index finger.

The following rules apply:

1. Only use lowercase. This prevents having to press two keys at once.
2. All common/popular functions should be reduced to only one character. Popularity = precedence.
3. If the function has a common name in every other language binding, we must change it to be easy to type. Standards and conformance are for losers.
4. All variables are implicitly typed (Ever heard of FORTRAN 77, young ones?). IDEs don’t always recognize primitive types, so we must get rid of them. Besides, words like double, boolean, float, and String have letters and require me to use both hands when typing. Arggh! Too much work.

Proposed changes include:
Math.random to Math.r
Math.cos to m.c
Math.sin to m.s
Math.tan to m.t
Math.atan2 to m.a2
gl.glEnable to gl.e
gl.glVertex[xx] to gl.v

With the release of Tiger, maybe we can even get rid of the m. and gl…

Seriously, OpenGL is a standard API and JOGL is a wrapper for this standard. This being the case, we should make the function names the same as they are in every other language binding. The fact that you have to call a member function from an object should not make you feel like we are in a whole 'nother world here. You will be very glad for the conformance when you have to read source in another language that has the same function names.

OpenGL is a standard. Let’s keep it that way.

[kbr]

[*]I think that the ability to create pbuffers should be available without the requirement to derive them from a viewable GLDrawable. They should also not be lazily created. AFAIK, I can create an offscreen RC in a C/C++ program without having to create an onscreen one. Why not the ability to do the same in JOGL?

Actually the reason behind the current pbuffer API design in JOGL is because it appears to be necessary (in all of the C/C++ code I’ve seen) to have an onscreen OpenGL context before the pbuffer’s offscreen context can be created. In the JOGL 1.1 source tree (what’s currently in the repository), it turns out we always create an invisible onscreen window and associated OpenGL context for the purposes of calling wglChoosePixelFormatARB and a few other routines (for FSAA support), so we might be able to change and/or simplify JOGL’s pbuffer API in the way you suggest.

[*]There should definitely be a user controlled swapbuffer command in the form of gl.glSwapBuffers() or something like that.

This was just added to the public API in the final 1.0 release.

[*]Make resources shareable across contexts. You can do this on most other platforms via calls such as wglShareLists. Of course, this would have to be abstracted away to something like joglShareLists.

This has been supported for a while. See the methods in the GLDrawableFactory which take a GLDrawable with which to share display lists and textures, and see the TestContextSharing demo in the jogl-demos workspace.

[shaddam_IV]

ken-
Thanks for the info on list sharing and other feedback.

BTW, anything I am suggesting as a “should” that has already been done means it should go into the “official” bindings, not that it should be implemented. I think the vast majority of the changes to the JOGL bindings since their inception demonstrate good design and should stay pretty much the same when things go “official”.

[abies]

Proposed changes include:
Math.random to Math.r
Math.cos to m.c
Math.sin to m.s
Math.tan to m.t
Math.atan2 to m.a2
gl.glEnable to gl.e
gl.glVertex[xx] to gl.v

I understand your pun, but situation is a bit different. Mostly everybody here want to have methods like Math.mathRandom, Math.mathCos, Math.mathAtan2, while I and blah^3 are advocating going for just Math.random, Math.cos and Math.atan2.

IF similary to C is really such top priority, then why using object at all ? All methods should be static in GL class, then with static import you will be able to write
glStart(GL_TRIANGLE)
and then I will agree that it is a really similar to C, which is a virtue in itself. But suddenly you are changing “opengl standard”, by requiring another prefix (gl.) and making it almost object-oriented ??? For me, agreeing to gl. and then telling about having to be letter-for-letter same in C is a bit contradictory.

As for the ‘binding in every other language’ it just reduces to C. Everybody else was blindly copying C implementation, which broke written opengl standard by adding prefixes to avoid namespace clash… Looking this way, we should be using zero-delimited char[] arrays when passing/requesting string from opengl binding, don’t we ?

[overnhet]

shaddam_IV : RTFM übern00b ! (sorry ;D I couldn’t resist)

Quoted from OpenGL 1.5 specs (GL command syntax, page 7) :

“The declarations shown in this document apply to ANSI C. Languages such as C++ and Ada that allow passing of argument type information admit simpler declarations and fewer entry points.”

I don’t know how you read it, but it seems that GL API is not carved in stone. Depending on the language capabilities you can produce a simplified binding which ease developers work without breaking the specs. IMO the bloated aspect of the C version is mostly due to language shortcomings.

Now there are pros and cons, and an oversimplified API would achieve the opposite of the desired effect. When googling around for Java/OpenGL bindings I found YAJOGLB (http://home.earthlink.net/~rzeh/YAJOGLB/doc/YAJOGLB.html), which use gl.vertex syntax. Here is an excerpt from the PlainCube demo :

  public void paint(GeometryViewer viewer, GL gl, GLU glu) {
    gl.pushMatrix();
    gl.rotate(30.0f, 1.0f, 1.0f, 1.0f);
    gl.material(FRONT_AND_BACK, AMBIENT_AND_DIFFUSE, material);
    gl.begin(QUADS);
    gl.normal( 0.0F, 0.0F, 1.0F);
    gl.vertex( 0.5F, 0.5F, 0.5F); gl.vertex(-0.5F, 0.5F, 0.5F);
    gl.vertex(-0.5F,-0.5F, 0.5F); gl.vertex( 0.5F,-0.5F, 0.5F);
    
    gl.normal( 0.0F, 0.0F,-1.0F);
    gl.vertex(-0.5F,-0.5F,-0.5F); gl.vertex(-0.5F, 0.5F,-0.5F);
    gl.vertex( 0.5F, 0.5F,-0.5F); gl.vertex( 0.5F,-0.5F,-0.5F);
    
    gl.normal( 0.0F, 1.0F, 0.0F);
    gl.vertex( 0.5F, 0.5F, 0.5F); gl.vertex( 0.5F, 0.5F,-0.5F);
    gl.vertex(-0.5F, 0.5F,-0.5F); gl.vertex(-0.5F, 0.5F, 0.5F);
    
    gl.normal( 0.0F,-1.0F, 0.0F);
    gl.vertex(-0.5F,-0.5F,-0.5F); gl.vertex( 0.5F,-0.5F,-0.5F);
    gl.vertex( 0.5F,-0.5F, 0.5F); gl.vertex(-0.5F,-0.5F, 0.5F);
    
    gl.normal( 1.0F, 0.0F, 0.0F);
    gl.vertex( 0.5F, 0.5F, 0.5F); gl.vertex( 0.5F,-0.5F, 0.5F);
    gl.vertex( 0.5F,-0.5F,-0.5F); gl.vertex( 0.5F, 0.5F,-0.5F);
    
    gl.normal(-1.0F, 0.0F, 0.0F);
    gl.vertex(-0.5F,-0.5F,-0.5F); gl.vertex(-0.5F,-0.5F, 0.5F);
    gl.vertex(-0.5F, 0.5F, 0.5F); gl.vertex(-0.5F, 0.5F,-0.5F);
    gl.end();
    gl.popMatrix();
  }

Is it that ugly ?

As far as I’m concerned, the main simplification I would like is redundant suffix removal (see my first post). The rest I don’t really care, but I think we should aim at the best readability / efficiency balance.

[blahblahblahh]

[quote]being able to communicate with the OpenGL world is a really handy feature of the current naming scheme. I have posted my jogl java code to openGL news groups and C programmers have had no problem understanding the code.
[/quote]
Are you saying that programmers who understand

gl.glVertex3f(…) == glVertex3f(…)

yet are too incredibly braindead to be able to understand that

glVertex3f(…) == gl.Vertex

are somehow intelligent enough that they can help you with your OpenGL problems?

[blahblahblahh]

[quote]What about some testing time:

Then let us use and evaluate this for some time and see whether it is nice or bad.
[/quote]
Unless someone (e.g. the GTG?) has a firm description of the intended audience that answers the issue outright, then this sounds like an excellent idea; isn’t it “just” a matter of adding some output options to automatic code-generator?

In response to: (crappy forums dont do recursive quoting)

You cannot really answer this issue without defining the audience.

In support of the above author and those with similar leanings, I propose a new JSR named “Break the standard in favor of fewer keys and obfuscated code for lazy programmers API”. Logically, the number would be JSR 7, since 7 is only one key and is easily reachable from my strong right index finger.

Funny :). But you also seem to have been serious…you are implying that you are able to decide what an API should be without considering who the users are. This is the stereotype of the useless geek programmer: someone who codes for other people but makes all decisions purely selfishly and hence ends up with software which no-one understnads, no-one can use, and only works on the author’s computer.

This says it all.

Are the java programmers less relevant than the C++ programmers? Is this java library are being developed primarily for the benefit of the non-java programmers?

Shrug. I don’t know; if the primary intent of JOGL is to ease migration for C++ programmers then sure - I’m all for being as identical to C-OGL as possible.

[princec]

We seem to have solved this problem in LWJGL and no-one’s complaining. At least, no-one we’re going to take any notice of

Cas