JOGL & OpenGL2.0: General Assessment?

[pkaku]

My company is interested in making a wholesale shift to Java+OpenGL_2.0 for a long-term project. I have taken a broad inventory of issues mentioned in this forum, but would appreciate additional information and opinions, especially with regard to the following:

–The general prospects for JOGL. Is it likely to remain the java-OpenGL binding of choice? Is there reason to expect a persistent or uneven lag between the bindings and the API, especially as we move beyond 2.0?

–The specific prospects for OpenGL Shaders. Is there any reason to expect a lag between JOGL and OpenGL in this particular area, especially given the benefit of driver-side compilation?

–The specific prospects for pbuffers. Are there any stubborn (i.e. currently unsolvable) performance or compatibility issues for render-to-texture under JOGL? Also, has any progress been made on the “lazy creation” problem mentioned in the user’s guide?

Apologies in advance if I’ve overlooked specific coverage of these topics in earlier posts.

Regards,

–Peter Kaku

[Orangy_Tang]

[quote]–The general prospects for JOGL. Is it likely to remain the java-OpenGL binding of choice?
[/quote]
Jogl is the binding of choice? When did that happen? IMHO after using both Jogl and LWJGL for several projects Jogl is still too buggy to recommend for any serious project. Equally development & updates are few and far between.

[quote]–The specific prospects for pbuffers. Are there any stubborn (i.e. currently unsolvable) performance or compatibility issues for render-to-texture under JOGL?
[/quote]
I have not used pbuffers myself, but Markus tried using them in Wurm yet abandoned them after finding that they caused most peoples machines to crash (including those with good nVidia and ATi cards with up to date drivers). I am not aware of any progress being made on this since then.

[wes]

–The specific prospects for OpenGL Shaders. Is there any reason to expect a lag between JOGL and OpenGL in this particular area, especially given the benefit of driver-side compilation?

you mean GLSL? and will they have slower compile time under JOGL? I think (please correct me if i’m wrong) a similar overhead to any other JOGL call would apply. The driver will still compile the shader as the JOGL calls are mapped to native methods though JNI. The ususal overhead would exist as the java objects are converted to data that the native gl functions can understand. (ie calling GetStringUTFChars, ReleaseStringUTFChars…etc)

[pkaku]

Jogl is the binding of choice? When did that happen? IMHO after using both Jogl and LWJGL for several projects Jogl is still too buggy to recommend for any serious project. Equally development & updates are few and far between.

Can I interpret this to mean that you would recommend LWJGL?

[pkaku]

you mean GLSL? and will they have slower compile time under JOGL? I think (please correct me if i’m wrong) a similar overhead to any other JOGL call would apply. The driver will still compile the shader as the JOGL calls are mapped to native methods though JNI. The ususal overhead would exist as the java objects are converted to data that the native gl functions can understand. (ie calling GetStringUTFChars, ReleaseStringUTFChars…etc)

Thx. This is as I had assumed. Just fishing for snags.

[princec]

I recommend LWJGL too But it depends on your actual requirements which API you’re going to use. If you’re doing CAD/CAM, grit your teeth and go for JOGL. If you’re writing portable games, go with LWJGL. We’ll very likely have GL2.0 support before JOGL, and OpenGL ES support. Of late I have wondered whether someone might actually implement the GLSlang compiler in pure Java too…

Cas