Re: [gl4java-usergroup] moving to jogl

[Kenneth B. R. <kbr...@al...>]

> But it seems there are less docs and demos for jogl than for gl4java

Yes, sorry about this. There wasn't enough time to produce a lot
of documentation as well as get Jogl and the demos done in time
for JavaOne. However, the javadocs for the core
net.java.games.jogl package should be pretty complete, and the
very terse "differences-from-gl4java.txt" in the doc subdirectory
should give GL4Java developers an idea of the major API changes.

Also, due to some confusion, almost none of the demos we ported
made it into the source distribution currently on java.net. This
should be addressed in the next week or so. We ported the
following non-Cg NVidia demos for JavaOne:
 - hw_shadowmaps_simple
 - infinite_shadow_volumes
 - ProceduralTexturePhysics (water simulation)
 - vtxprog_refract
 - vtxprog_warp

and the following Cg-based NVidia demos:
 - runtime_ogl
 - runtime_ogl_vertex_fragment
 - High Dynamic Range rendering demo (which we don't have
   permission, at least not yet, to release sources for)

> I've got few questions :
>  
> - are all gl4java capabilities supported in jogl ?

All of the functionality of GL4Java and more is supported; OpenGL
1.4 plus all vendor extensions are supported in Jogl. There are
a few APIs which are still not exposed to Java because they use
complex constructs like void **, but these will be addressed
soon.

Additionally Jogl has platform-agnostic support for pbuffers in
the public API. Currently they're only implemented on Windows but
an X11 port should be done soon.

Eventually slides from our JavaOne talk should show up at
http://java.sun.com/javaone/ ; these include an overview of the
differences among GL4Java, LWJGL, Magician, and Jogl. We'll also
write up some HTML documentation on this and check it in to the
source tree in the near future.

> - is it stable ?

In terms of API changes Jogl should be fairly stable; that is,
it's likely that only API additions and not removals and changes
will be done going forward.

In terms of the stability of the implementation I'd like to say
that it should be more stable than Gl4Java. The OpenGL context
handling and interaction with the window system has been
completely redesigned and is in fact now written in Java instead
of in C. If something goes wrong, an exception is thrown instead
of a VM crash. There are still some features missing like correct
support of adding/removing GLCanvas objects from a frame over and
over again, but this should be a relatively small addition and
I'm hopeful that it can be done without changes to the public
API.

> - I look at a demo, it seems that there are little things to
> change from a GL4JAVA app to a JOGL app , am I right ? (add an
> Animator object, all consts in GLENUM class are translated to
> GL . XYZ)

Yes, in general there are only relatively minor changes required
to move from GL4Java to Jogl, though if you'd been using, for
example, the GLContext class in GL4Java to manually swap the
buffers then your application will require more restructuring.
See the documentation in differences-from-gl4java.txt. There is
also a script called net.java.games.gluegen.opengl.ConvertFromGL$Java
which will make most of the source-level changes for you.

-Ken