JOGL and enum.

OpenGL Development JOGL Development
#1

When I browsed JOGL docs I saw a lot of static fields that are representing enum values from OpenGL.
Did you planning to replace these fields by
Java 1.5 enums? Or new version of JOGL must be full compatible with previous
and this is out? Or maybe this would be too expensive for performance?

#2

You would need to write something like

gl.glBegin(GL.GL_TRIANGLES.value);

instead of

gl.glBegin(GL.GL_TRIANGLES);

I don’t think it is worth it. It would be different, if in some magical way, compiler would know what values are allowed for which functions… but even opengl spec has no idea about that (as every extension can change that), so I don’t think it is possible.

#3

Those glXxxx() methods are part of the JOGL wrappers around native calls to the OpenGL libraries on their respective platforms. Those wrappers could easily be extended to support enumerations. Just overload all those methods, so:


interface GL {
   static int GL_TRIANGLES = xx;
   static int GL_TRIANGLE_STRIP = xx;
   static int GL_TRIANGLE_FAN = xx;
   ...
   public void glBegin(int mode);
}

gl.glBegin(GL.GL_TRIANGLES);

would become something like:


public enum BeginMode {
   GL_TRIANGLES(xx),
   GL_TRIANGLE_STRIP(xx),
   GL_TRIANGLE_FAN(xx),
}

interface GL {
   static int GL_TRIANGLES = xx;
   static int GL_TRIANGLE_STRIP = xx;
   static int GL_TRIANGLE_FAN = xx;
   ...

   public void glBegin(int mode);
   public void glBegin(enum BeginMode);
}

gl.glBegin(BeginMode.GL_TRIANGLES);

et voila, you either continue like you were used or you can decide to start using enumerations.

#4

In general, yes, that’s how enums work. But there are two problems with using them with jogl:

1.) in order to use them you would call
gl.glBegin(BeginMode.GL_TRIANGLES);
while the C equivalent is
glBegin(GL_TRIANGLES);
so while this might be nice if you have an IDE that gives you a list of possible values, so you can just choose among the different BeginModes, the resulting code looks much different from the c code which makes JoGL code harder to read/write if you are used to using “normal” C-based OpenGL.

While this might sound purely cosmetic, it makes it for example harder to post snippets to C-centric GL-Forums, etc.

2.) Jogl creates the GL-class programmatically from the gl.h and glext.h header files. Since in these header files, there’s no info about which values are being accepted by the different functions, you would have to somehow parse the extension and GL-spec in order to get this info. Since they are not easily parsed, this is a rather hard task and even then you might miss some values if a certain spec is formatted a little bit differently.
You could manually define these values, but this would kill the advantage of the automatic class-generation. That is that with a new exception coming out, you just have to recompile jogl in order to get access to the new functions and constant.
If you now define the enums manually, a new spec that introduces for example a new texture-format requires you to add that format by hand to the TextureMode-enum.

just my 2 cents

Jan

#5

  1. True, but the Java variant gl.glBegin(GL.GL_TRIANGLES) is also different from the C version so I don’t see much of an obstacle there.

  2. You’re absolutely right, hadn’t thought about that :slight_smile:

So for JOGL this might not be a very good solution, but it remains a viable option in other cicumstances. I was actually referring more to abies’ remark that there isn’t much of an advantage to using enums (while I can’t wait for Eclipse to support the 1.5 JDK :))
.