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.

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.

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.

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.

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.

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 Either i'm searching for the wrong things, or it died with the previous boards.

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.

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

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 ).

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org