Here is a fairly long list of decisions already made by the JSR 231 and 239 Expert Groups as well as a couple of issues needing further discussion. Please post your comments.
Some of these issues have been raised on these forums already, such as exposing GLContext in the public API. The expert group decisions were made on the basis of supporting more styles of application rendering (in particular rendering in parallel to multiple contexts on the same drawable) as well as providing lower-level control to applications desiring it. We aren’t in a position to publish a specification on these forums yet, but if you subscribe to the cvs@jogl.dev.java.net email list you’ll be able to see the checkins that will morph the current JOGL APIs toward the JSR 231 APIs.
Currently the plan is to create a branch of the JOGL source tree under which to do the initial work. Once the APIs have stabilized and they are implemented on all platforms we’re planning to revisit the issue of folding this branch back in to the main JOGL trunk, though doing so will break existing JOGL applications since there will be some incompatible API changes.
Decisions that have been made:
[]The C naming conventions for OpenGL functions will be preserved: for example, glVertex3f.
[]The APIs will be window system-independent and not be inherently tied to the AWT. From a practical standpoint this means:
[list]
[]Interfaces like GLDrawable which are not tied to a particular AWT component will remain in the public API. However, concrete components like GLCanvas will also remain in the public API.
[] A Service Provider Interface (SPI) will be present to allow new implementations of the GLDrawable interface to be created by vendors. For a concrete example of this see Alex Radeski’s notes: http://members.iinet.net.au/~alexr/jsr231-notes.html
[*]Platform-specific extensions to OpenGL (WGL, GLX, CGL, EGL) will not be exposed in the public API. Instead, platform-independent abstractions will be provided that bridge these window system-specific APIs.
[*]Part of this decision was overturned in a later JSR 239 vote in which the attending EG members voted to expose the EGL interfaces in the public API. Some of the EG members felt that it was only necessary to expose EGL if it wasn’t possible to expose all of the EGL functionality in a higher-level API. Even if EGL is exposed, it may still be possible to provide an abstraction layer to provide some source code compatibility between the 231 and 239 specs.
[]GLCanvas and GLJPanel will be made non-final.
[]The GLContext will be exposed in the public API. This decision was made to make it easier to structure certain types of applications as well as to allow more low-level control over rendering. There will be both a low-level and a higher-level rendering layer, the higher-level layer providing the GLEventListener callback mechanism currently present in JOGL. There will be synchronization mechanisms built in to the GLContext to make it possible to implement the current callbacks on top of public APIs.
[]It will be possible to wrap an existing Canvas (or other appropriate GUI element) with a GLDrawable, rather than requiring use of the GLCanvas class.
[]It will be possible to create multiple GLContexts per GLDrawable.
[/list]
Issues we are aware of that need further discussion:
[]Vendors need to be able to add extensions without changing the public API and thereby causing the signature tests to fail.
[list]
[]One way to implement this would be for the vendor to subclass the GL interface into e.g. NVidiaGL and provide the methods and constants corresponding to the new extensions in that subinterface. Users would then be required to downcast the GL interface to NVidiaGL in order to access the extension.
[*]Another, possibly better, way to implement this would be to add a method like
public Object getExtension(String extensionName);
to the GL interface. The user would be required to know the type of the returned Object in order to cast and call methods on it. LWJGL’s support for OpenGL extensions is similar to this.
[*]The intent would be to fold new extensions into the core GL interface as quickly as possible.
