JOGL Exposed

OpenGL Development JOGL Development
#1

This is a continuation of this discussion:

http://www.puppygames.net/forums/viewtopic.php?t=83

I figured it needed to move here now that the forums are reopened. :slight_smile:

[quote]Everything in the util package is, as you said, a “we need that quick” class. They’re not intended to be “jogl”… rather, they were helper classes that a bunch of the demos used. But since the demos didn’t all get posted (yet), their presence is misleading. They should probably all go in *.demos.util; nothing in the jogl “core” depends on any of them.
[/quote]
Ok. So can I safely assume that net.java.games.jogl is the only real API? If that’s the case, there are only a couple of comments I have about it.

  1. The XVisualInfo docs state that the class is useless to the end developer. Shouldn’t it be hidden?
  2. A model loader/texture loader API is probably needed as a separate project from the JOGL stuff. Many of the UTIL classes could move there then.
  3. DurationTimer should probably be forgotten about. It’s a very confusing implementation. There are plenty of good timers out there. If you’d like, you can take my GAGETimer and roll it into a utility project. I won’t mind. :slight_smile:

Beyond that, I’d just have a few semantic disagreements. I personally don’t like the idea of the “static imports” and would much rather see the “gl” dropped from method names. That’s just my opinion tho, so take it for what it’s worth. :slight_smile:

#2

There are some X11-specific OpenGL extensions which refer to the XVisualInfo data type. These extensions are exposed in the public interface GLX. For this reason the XVisualInfo class was exposed in the public API rather than put into an implementation package; we didn’t want to unduly limit the usefulness of any window system-specific extensions though to be honest not too many can be taken advantage of by end users since they require information not provided by the library. However, they are used by the implementation; for example, the pbuffer implementation on Windows uses the publicly-visible WGL extensions heavily.

The model loading code was “quick and dirty” as is probably apparent. We only put in exactly what was needed to get the demos we needed to port working. Some more one-off loaders will be checked in along with the demos.

DurationTimer was a quick hack to get some framerate statistics out of some of the demos and can be deleted at pretty much any time. I did add another set of timer classes for animation purposes which will show up in the source tree as soon as we get clearance to post the source code for the demos, at which point more discussion can usefully be had about what’ should go where and what should be changed.

There are several strong technical arguments against changing the GL interface to be a class with static methods. Regardless, the naming convention of the methods themselves will almost certainly not change.

#3

[quote] Regardless, the naming convention of the methods themselves will almost certainly not change.
[/quote]
Could you please explain the rationale behind sticking to gl.glEnable/gl.glColor3f instead of gl.enable/gl.color3f ? Legacy programs already ? Easier to conver programs from C (replace gl->gl.gl instead of gl -> gl.<and_change_next_letter_to_small) ?

#4

[quote] Could you please explain the rationale behind sticking to gl.glEnable/gl.glColor3f instead of gl.enable/gl.color3f ? Legacy programs already ? Easier to conver programs from C (replace gl->gl.gl instead of gl -> gl.<and_change_next_letter_to_small) ?
[/quote]
I can’t sate why JOGL did this, but I suspect that it is the same reason for it, that is causing LWJGL to do this too.
Static imports in Java 1.5.

thus:
gl.glEnable(…) becomes:

<in the top of java file)
import org.lwjgl.opengl.GL;

glEnable(…)

you would then not need to modify the methodnames of any of your c sourcecode

#5

I could understand the reason of static imports, but Ken just said they are against static methods. So my question is: Why gl prefix with instance methods ?

#6

The decision to leave the method names alone was not made based on the future use of static imports. The names were left unchanged simply because all of the existing documentation and code refers to those names, and changing them would cause unnecessary confusion.

-Ken

#7

If you’re not planning on using static imports, why not remove the ‘gl’ prefix from all the methods?

Personally, I think its redundant and daft to include them. The original names were C names, and so with no proper namespacing the prefix was needed. By having a GL class then function name collisions are automatically avoided.

There was a thread about this when LWJGL had to make the decision (way before static imports were likely) and the overall majority was for the gl.Enable() style instead of the redundancy of gl.glEnable().

Edit: I can’t find the thread :frowning: Either i’m searching for the wrong things, or it died with the previous boards.

#8

I believe at least part of that discussion was on SourceForge…

Ah, found it:

http://sourceforge.net/forum/forum.php?thread_id=718108&forum_id=196813

Edit: And heh, it may not be publically linked anymore, but if you know where to look… ;D

http://www.java-gaming.org/discus/messages/141/1582.html

#9

Bah, the gl prefix is far too trivial to argue over.

It really isn’t going to have a meaningful effect on anything in the long run.

#10

[quote]I believe at least part of that discussion was on SourceForge…

Ah, found it:
[/quote]
Uncannily enough, that was exactly what i was trying to find :slight_smile: I’m sure the concensus remains with striping the prefixes…

#11

What’s old is new again…

Alligator Descartes and I hashed thru the Java vs ‘C’ method names debate SEVEN years ago. Alligator wanted backward compatibility to facilitate porting. I wanted rational bindings for Java.

It was then covered again by the ARB in 1998.

Our compromise was to have both. Included in the bargain were convenience methods, for instance GL.color( java.awt.Color ).

And before anyone freaks about code bloat, that’s what packagers like IBM’s JAX are for.

#12

It would be easy to modify BuildComposablePipeline.java to emit another pipeline which contained non-prefixed calls wrapping their prefixed base methods (e.g., color3f() calling glColor3f()). This modification would probably take 10 minutes, tops.

This would, as Jason suggested, give you the best of both worlds.

-chris

#13

Hi Chris-

[quote]…another pipeline which contained non-prefixed calls wrapping their prefixed base methods (e.g., color3f() calling glColor3f()).
[/quote]
Hey, thanks for listening!

In Magician, the type denoting suffixes were also dropped for the Java-ified names. For example, color( float, float, float ) in place of color3f( float, float, float ).

Cheers, Jason

#14

This is not a poll, but yet another, maybe a bit funny argument in favor of dropping prefixes: Even official opengl document list function names and constants without GL prefix (example
http://oss.sgi.com/projects/ogl-sample/registry/ARB/transpose_matrix.txt
) - gl/GL_ prefixes are unfortunate requirement of flat C namespace.

#15

I doubt I’ll have any influcen on JOGL API but when I write an API at my work I try to think What Would XXX Do? :slight_smile: Where XXX is Joshua Bloch or Ken Arnold. The Java API has it’s fair share of warts but from what I’ve seen of the APIs crafted by these two I really respect their opinions. (I’ve found the four intervies in the second section of the Artima Design Corner be good reads.)

Anyway, JOGL is an OpenGL API so you don’t really have the flexibility to make all the design decisions but there is reasonable flexibility when adapting the C API to a Java API.

I belive the arguments for of preserving the gl prefix doesn’t carry much weight when you move out of a flat namespace. I give the most weight to the aguments for making the API the easiest for the programmer to read and understand.

My OpenGL experience is minimal, so I’m not going to claim to be an authority on OpenGL usability but that’s my $0.03 cents as it applies to APIs.

#16

Unfortunately, this doesn’t work for vertex2fv versus vertex3fv - they both expect float[], just with different lengths. So, at least for ?v calls, suffix has to stay - but if it stays for them, it should probably stay for all methods.

I have modified composable pipeline class to generate ShortGL wrapper, which contains names without prefixes. Unfortunately, due to reflection-only way it works, parameter names are lost, which IMHO is not worth the gain from more clear method names. If at some point composable pipeline will become full GlueGen-based stage, then we can get back to that idea.

#17

You could never get rid of the signed/unsigned “u” suffix either…