jogl API feedback requested for JSR 231

OpenGL Development JOGL Development
#1

As most of you are probably aware, jogl will be used as the starting point for the Reference Implementation for JSR 231 Java bindings to OpenGL (see http://jcp.org/en/jsr/detail?id=231). The people who read this forum have some of the most experience with this API. I would like to solicit your feedback regarding the jogl API.

I don’t want “jogl crashes when I do x” type of issues. While legitimate problems, they are not tied to the creation of an API specification. Assuming everything worked 100% as advertised, what parts of the API would you want to see changed and why. The better the explanation, the better the JSR 231 Expert Group will be able to determine the importance of the issue.

Please note there are no guarantees that any issue posted will be addressed, the Expert Group will decide how best to deal with all issues.

As a starting point, here are the issue I thought were relevant from the open issues in the jogl.dev.java.net project:
52 Current GLU semantics need to be properly encapsulated
63 NoAutoRedraw paint behavior
27 convenient usage of jogl from a jdk perspective

d

#2

I think theres a fair bit of interest in this concept of abstracting away the window/canvas management, i.e. removing the dependancy on AWT, or does this break JCP in some way?

Kev

#3

I think there is one very big problem which can be even a showstopper - safety. Currently, it is possible to do almost everything (crash machine, probably even take over root) using JOGL, as it allows to overflow native buffers by driver. I think it would be first JSR api which would allow such thing. To avoid it, a large number of checks would have to be made for many calls - slowing things down and probably not catching all cases anyway, given number of drivers/environments.

With java3d, it was possible to crash jvm using some bugs - but this was just crashing virtual machine and it could be fixed. Here, more serious danger is present by very design of exposing direct driver calls. This means that opengl binding would have to be out-of-reach for anything what does not have ‘all-permission’. Even for such code, exposing api which make it trivial to crash jvm (at least) is a bit strange for JCP…

Reassuming - I don’t think it is possible to provide safe opengl binding, especially safe for non ‘all-permission’ code usage - it can be a major point for design discussion.

On the other subject, it would be nice if gl prefixes could be removed from methods - they are really redundant and make IDE job very hard (at is often starts to autocomplete after first or second letter, resulting in HUGE hint list).

Please also think about removing suffixes - java overloading should help in many cases here. Not really sure about it, because sometimes it could be ambiguous…

And my pet sleeve - VBO should use int for offsets, not ‘offset buffers’ - IMHO it is a hack, which does not protect from crashes/misuse anyway.

#4

[quote]I think theres a fair bit of interest in this concept of abstracting away the window/canvas management, i.e. removing the dependancy on AWT, or does this break JCP in some way?

Kev
[/quote]
Do you have a concrete suggestion on how to do this? The GLDrawable interface is designed to abstract away the differences between GLCanvas and GLJPanel. I don’t see any technical reason why we couldn’t have a GLFullscreenDrawable interface with a couple of extra methods and a new GLDrawableFactory.createFullscreenDrawable() API. However, the built-in full-screen functionality of the AWT seems to work in at least most cases.

#5

  1. No additional safety checks please, it could kill performance and make it really difficult to compete with native apps. Wouldn’t a big “WARNING : Don’t mess too much with buffers” be sufficient ? ;D

  2. Restricted permission could prevent the use of OpenGL in applets, so this decision shouldn’t be taken lightly (IMHO OpenGL applet could be a great way to draw people into java game development).

  3. I second the removing suffixes proposal, “duplicated” functions clutter the API.

For example, glActiveTextureARB and glActiveTexture are exactly the same thing so it would make sense to merge them into a single glActiveTexture call which would fall back to glActiveTextureARB if necessary.

If I understood the whole ARB process correctly, we could suppress every ARB suffixes. As of EXT suffixes I don’t know : is there the any guarantee that they would keep the same meaning if they were promoted to ARB or core ?

  1. VBO offset : I haven’t used them yet but any nice, non native way to handle them would be welcomed :slight_smile:
#6

The support for controlling buffer swapping. See the thread:

  Vote time: RFE - Developer controlled swap buffer
#7

I like to think that the VBO issue is fixed nicely within LWJGL, by tracking the current VBO buffer and then allowing for int offsets only when the buffer is != 0. It’s a bit tedious to track it because of glPush/PopClientState and the overloaded methods, but it’s worth it imho.

Furthermore, we’ll very soon begin working on abstracting out the rendering context from the rest of LWJGL. Please let’s not duplicate the efforts again by being blind to the alternatives…

  • elias
#8

Cas seemed to have to pretty well thought out ideas here:

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1077270484

The objective was to support API clients of JOGL (e.g. Xith3D) being able to abstract away which rendering layer they were using cleanly. The dependancy of JOGL on AWT makes it pretty messy to support LWJGL or any other native implementation (DirectX one day?) as an provider of a rendering layer.

Kev

#9

I would really like the API ro remove all the redundant gl and GL instances.
Isn’t:

gl.texParameteri (GL.TEXTURE_2D, GL.TEXTURE_WRAP_S, GL.CLAMP);

so much cleaner than:

gl.glTexParameteri (GL.GL_TEXTURE_2D, GL.GL_TEXTURE_WRAP_S, GL.GL_CLAMP);

#10

Are you getting carpal tunnel from typing GL_? Seriously though the spec says GL_ so I think we should do GL_. I am an ee so I may be overly anal.

#11

Better multihead support definitely needed. Sometimes it is needed to run JOGL programs on multiple different heads from different and the same Java VMs. Currently I use modified version of JOGL with a patch from Issue #45 “JOGL multihead fix for linux” to run JOGL application (actually, Xith3D app) on 8- and 12-headed systems, but it would be really better to define screen during context creation via GLDrawableFactory and leave GLCapabilities to define requesting context capabilities.

Yuri

#12

[quote]I would really like the API ro remove all the redundant gl and GL instances.
Isn’t:

gl.texParameteri (GL.TEXTURE_2D, GL.TEXTURE_WRAP_S, GL.CLAMP);

so much cleaner than:

gl.glTexParameteri (GL.GL_TEXTURE_2D, GL.GL_TEXTURE_WRAP_S, GL.GL_CLAMP);
[/quote]
The GL. in GL.GL_CLAMP goes away automatically in Java1.5 when using static imports.

The gl.glFunctionName should stay and will have to stay to be OpenGL standard compliant.

#13

Sorry to be picky about this issue, but I don’t think it is true. I have just opened OpenGL 1.5 spec and functions does NOT have any prefix. If anything, then C library is not standard compilant, because it added gl prefix trying to work around lack of namespaces. [1]

AFAIK, only reason for leaving glVertex3f as it is was to make copy/paste porting from C easier. Search/replace gl -> gl.gl is easier than Search/replace gl -> gl.[and next letter to lowercase]. My solution was to leave method names with big letters (thus conforming exactly to opengl spec), but different choice was made by JOGL maintainers.

[1] - additionally, it is explicitly allowed to omit 3f from Vertex3f if language allows for that. GLSpec 1.5, 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.”

#14

Are you saying the 1.5 REMOVED from the C functions the gl?
i.e. any sample existing OpenGL code would break horribly?
Typical OpenGL C code…
void display(void)
{
glClear(GL_COLOR_BUFFER_BIT);
glIndexi(RAMP1START);
glPushMatrix();
glRotatef(-rotAngle, 0.0, 0.0, 0.1);
glBegin (GL_LINES);
glVertex2f (-0.5, 0.5);
glVertex2f (0.5, -0.5);
glEnd ();
glPopMatrix();
glFlush();
}
I am searching the spec right now, but I think you are misunderstanding it ( I hope!).
Can anyone else confirm this?
“gl” is dropped from OpenGL function calls?

#15

Well, the spec document may not declare the use of the prefix “gl” in OpenGL functions…
But I am not aware of a single C API implementation that doesn’t have.
Interesting though…probably can yank it without violating the “standard”
But then code all over the world would fail to recompile…

#16

[quote]Well, the spec document may not declare the use of the prefix “gl” in OpenGL functions…
But I am not aware of a single C API implementation that doesn’t have.
Interesting though…probably can yank it without violating the “standard”
But then code all over the world would fail to recompile…
[/quote]
Of course, ALL C implementations out there use gl prefix. Question is, if java binding should be a java-wrapper-around-C or java-wrapper-around-OpenGL. In both cases C library will be used under the hood (unless somebody will do some kind of special, java-only driver for X for example ?), point is what are we looking at when binding is made - opengl.h header, or OpenGL spec.

In no way I’m advocating creating C library without prefixes - with lack of namespaces, it would be a mess with generic names like Enable/Disable. But these gl prefixes are just a hack that need to be added in C, I see no point in copying them to java, just because they are in C. If big letters at start of method name can stay, then converting C code to java will be trivial - just add . after every “gl”.

I think same should be done for static values, but this is of secondary importance to me, given availability of static imports in 1.5. Choices are:
a) gl.glBegin(GL.GL_TRIANGLE_STRIP);
b) gl.glBegin(GL_TRIANGLE_STRIP);
c) gl.Begin(GL.TRIANGLE_STRIP);
d) gl.Begin(TRIANGLE_STRIP);

With b and d using static import and c and d using version without prefixes. For me personally, d look like native java binding, while a/b clearly are just ports to java. Isn’t it giving a message like “You should be using C if you want to use OpenGL, what are you doing here !?” ? Please also read all 4 versions aloud - d one sounds like what are you really doing :slight_smile:

#17

I think that removing the “gl” prefix from the OpenGL method names will cause a lot of confusion. If it is removed and nothing is done to the following letter (i.e., make it lowercase), the method names no longer conform to the Java guidelines. If it is removed and some rule is applied to the following letter, there will be some cases where special treatment will be needed where the “gl” prefix is followed by two or more capital letters. Either way, it’s going to be non-obvious how to read OpenGL documentation written for C/C++ and transliterate it to Java.

Given the reality that the OpenGL API is implemented at the bottommost level in C, I don’t think we should try to hide this fact by changing constant or method names. It’s been tried before in APIs like Magician. It resulted in a lot of overloaded methods, and the original methods were kept anyway to avoid confusing end users.

#18

Two issues that seem 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

  2. Integrating with the AWT event queue. Different methods of bridging the awt thread to the gl thread (queues?) should be investigated and possibly included as a standard part of the library.

#19

Since Ken Russell requested problems also be discussed on this thread, the big show stopper for me is the reshape problem which causes system hangs. It’s been discussed quite often, most recently on the java-seed@lists.apple.com list under the topic:

Re: OT: JOGL Re: Still getting link issues with JNLP

pdj
#20

Actually let’s keep the bug discussions to other threads as Dan requested. The reshape hanging issue is one I consider serious and plan to investigate soon, or if others have time to do so please post any progress made.