[gl4java-usergroup] about JoGL

[<aco...@mi...>]

Here is an interesting post I found on puppygames.net about JoGL from
one of the authors :

Hi Paul, 

As one of the two authors of Jogl (formerly known as "Jungle"), I can
assure you that Jogl is most definitely *not* a port of GL4Java. It is a
completely new binding for OpenGL under Java 1.4, written from the
ground up. It has several interesting features: 

1) It is completely autogenerated from the
gl/glext/wgl/wglext/glx/glxext.h headers. When a new GL extension comes
out, just re-run the make process and you'll instantly have access to
the new function. 

2) It comes with a C->Java binding generator that is used for the
process mentioned above. This generator parses C header files using a
full GNU C grammar and builds an in-memory mapping of all typedefs,
enums, structs, pointers, function pointers, etc. It then builds a
parallel mapping of Java methods and structures to the C equivalents,
and writes all the Java code and JNI code necessary to link the two
together. In fact, it's powerful enough to allow you to call C functions
that use C structs as parameters or return values, and builds Java-side
accessor classes that wrap NIO buffers. This gives you super-fast,
completely safe access to native data (no need to pass raw pointers
around). IMHO, the "GlueGen" generator that Jogl uses to generate the GL
binding is more valuable than the binding itself. 

3) It has a clean, autogenerated, platform-independent API for offscreen
drawing surfaces (pbuffers), as well as platform dependent routines line
glAllocateMemoryNV(). 

4) It cleanly handles all the platform-dependent complexities involved
with determining whether or not a GL function is callable (meaning it
can be called on the host and will do something useful on the client) at
runtime. This takes into account the GL versions of the server and
client, and the extensions that are exposed on the client and server.
Pretty handy, especially if you run on a multimonitor or networked
machine. It has hooks to handle the case in which you drag a window from
one display (or host) to another, but this is currently waiting on
additional JDK support before it can be implemented effective on e.g.
Linux. 

5) It has composable pipelines, much like Magician did. So you can swap
your GL for a DebugGL at will, and DebugGL will do all kinds of error
checking under the hood to find GL error conditions in your application.
This is invaluable for debugging. 

6) It's clean. Ken Russell, the other author, works on the Hotspot team,
and went to great lengths to make the internals of the AWT/Swing
integration very simple and clean, yet handle all the boundary cases. I
think you'll find the source code for GLCanvas much easier to understand
and maintain than that of GL4Java. 

Oh, we also used the GlueGen to build a Java binding for NVidia's Cg
language; it's pretty slick. Unfortunately it's not up on the site yet
as we're still migrating stuff from our private CVS server. Hopefully it
will be there soon, along with all the cool demos we've ported for our
JavaOne talk tomorrow. 

At the very least, please check it out; we tried hard to integrate the
best ideas from LWJGL, Magician, and GL4Java while keeping it fast,
clean, and easy to use. And remember, Jogl is intended to be part of a
community development process, so we're eager to hear about your
impressions and suggestions for its development. I think that forums and
mailing lists will be set up on the new site soon. 

-Chris Kline