turquoise3232 is correct, but there is a stupid legal reason why we don't distribute a zip archive of the javadoc, which is that officially we need to implement a click-through license for it. We've worked around this for the time being by putting the unzipped javadoc from the nightly builds on the JOGL home page.

How do GLDrawable#createContext and GLAutoDrawable#getContext interact? In other words, if I have a GLAutoDrawable instance that has created its own context and later on I call createContext on this instance, will this cause problems? The same question goes for calling createContext multiple times on a GLDrawable instance.

There are no problems with doing this. The GLAutoDrawable implementations simply automatically call createContext() once, hold on to the result internally, and return it whenever getContext() is called. It is legal to create another context for a GLAutoDrawable or for any arbitrary GLDrawable. The demos.context.DualContext demo shows one possible use of the createContext API, though it doesn't call it on a GLCanvas but a custom Canvas subclass.

JSR-231 beta 3 has been released on February 17, 2006. This release is intended to match the Proposed Final Draft status of the JSR. You can download the binaries from java.net.

In the JSR-related APIs, there is one incompatible change:

The setOffscreen* methods in GLCapabilities have been renamed to setPbuffer* for clarity.

There are also some changes to the javadoc which do not impact compatibility:

Removal of many implementation-specific references in the specification, or called them out explicitly as applying only to the reference implementation and not to the specfication or implementations in general. Clarification in various API areas.

Added overview section on context sharing

Added overview section on runtime version information

Changed name of properties in Threading class that contained "jogl"

In the non-specified APIs (in particular, the helper routines under com.sun.*), several changes have been made:

The namespace com.sun.opengl.utils.* was renamed to com.sun.opengl.util.* and several class names were changed from plural to singular to more closely match the naming convention in the core platform.

By popular demand, control over gamma, brightness and contrast has been exposed under the com.sun.opengl.util.Gamma class.

Some more routines were added to the Screenshot and ImageUtil classes to support taking snapshots containing alpha channels.

Brian Paul's tile rendering library has been ported to Java by user bleb here on the forums and, with Brian's permission, incorporated into com.sun.opengl.util. This utility makes taking print-quality screenshots very simple. A demo has been incorporated under demos.misc.TiledRendering in the jogl-demos workspace.

A few more JOGL demos have been incorporated including picking using the selection buffer and writing a custom GLCapabilitiesChooser.

Additional minor changes and bug fixes.

Going forward we do not anticipate any more incompatible API changes. This last round of changes was done to achieve better consistency and clarity in the APIs before they are finalized.

There are more plans to change the implementation to be more scalable in particular on multi-head X11 systems, but these changes will not impact the public API.

Please try the new builds and post with any comments or problems. Thanks.

The version information has been incorporated into the jar's manifest and is accessible through the java.lang.Package API. getImplementationVersion() is probably what you want. See the demos.misc.VersionInfo demo for an example and the source for the JOGLAppletLauncher in com.sun.opengl.util for a concrete place where a use of the Version class was replaced with Package.getImplementationVersion().

JSR-231 beta 4 has been released on April 20, 2006. This release is intended to provide robustness and scalability improvements, but does not change the public API.

The following improvements have been made:

The locking protocol used by the on-screen GLContext implementations on all platforms has changed. The new protocol locks the drawing surface using the JAWT for only the minimal period of time necessary rather than during the entire duration between the makeCurrent() and release() calls. This primarily enables simultaneous rendering to multiple displays on multi-head X11 setups. Note that on some graphics drivers (ATI's proprietary drivers, in particular) this optimization does not work, so for complete correctness it is still typically required to call release() periodically rather than simply makeCurrent() once and leaving the context current. This is only an issue if applications are manipulating the OpenGL context directly rather than using the GLEventListener paradigm. If necessary, the old locking behavior can be restored by specifying -Djogl.GLContext.noopt on the command line.

A bug fix to the X11ExternalGLContext used by the Java2D/JOGL bridge as well as by the SWT snippets which use JOGL.

Bug fixes and improvements to the com.sun.opengl.util and com.sun.opengl.util.texture classes.

Added support to the Java2D/JOGL bridge for Java2D's EXT_framebuffer_object (FBO) mode. This may become the default mode of the Java2D/OpenGL pipeline in later Mustang builds, and can be tested with current Mustang builds by specifying -Dsun.java2d.opengl=true -Dsun.java2d.opengl.fbobject=true on the command line. Using FBOs for Java2D's OpenGL support seems to eliminate the slowness seen on certain NVidia cards with Romain Guy's Twinkle demo, for example.

Improvements to JOGL's support of DRI-based accelerated drivers on X11 platforms.

A workaround for an apparent pixel format selection bug in Intel's OpenGL drivers on Windows for 82855 and similar chips.

A patch from user cylab on these forums to generate javadoc links to the on-line blue book. Currently only the OpenGL 1.0 APIs are covered. Help is needed from the community to improve this support; please see this thread.

The native library jar files have been renamed to be more precise about the OS and CPU combination they work on, in preparation for 64-bit builds and builds on more platforms.

Universal binaries for Mac OS X for this release are finally available both for download as well as via Java Web Start and the JOGLAppletLauncher. They will be added to the nightly builds soon.

There are also some known issues:

We attempted to introduce a "GL worker thread" separate from the AWT Event Dispatch Thread (EDT) upon which all OpenGL context manipulation would be done, to maintain the default single-threaded model while decoupling from the EDT. Unfortunately for various reasons this did not work; on X11 platforms there is a potential deadlock, on Mac OS X the JAWT is unstable when used from a non-EDT thread, and on Windows platforms stability issues are introduced with applets. For the time being and for the initial reference implementation of the JSR we are planning to leave JOGL's internal threading model as it currently stands.

There appear to be stability issues (intermittent crashes) with JOGL-based applets on X11 platforms (Linux, Solaris/x86) when entering and leaving the page with the applet at least with NVidia's proprietary drivers. It is not clear whether these issues are new in beta 4 or are preexisting problems. We currently can not recommend applet-based deployment as a good solution for JOGL users and instead continue to recommend using Java Web Start.

Please try this release and post any feedback, in particular regarding its quality. Stability is our top priority, especially between now and the release of the 1.0 version of the JSR-231 reference implementation.

JSR-231 beta 5 has been released on June 8, 2006. This release improves robustness; there are no public API changes.

The following improvements have been made:

In JSR-231 beta 4 an optimization to the locking protocol for on-screen GLContext implementations was added, in particular to support simultaneous multi-screen rendering on X11 platforms. Unfortunately it appears that there are correctness problems with this optimization using both NVidia's and ATI's drivers, so it has been disabled by default in beta 5. The implication of this change is that you should not leave a GLContext permanently current on a thread, but rather should make it current and release it every frame so that on all platforms the AWT has a chance to dispatch its events. (This was basically how things worked in all releases before beta 4.) The optimization may be re-enabled by specifying -Djogl.GLContext.optimize on the command line. This is documented in the JOGL User's Guide.

A couple of fixes to the Java2D/JOGL bridge, some of which were regressions due to the new support for the Java2D/OpenGL pipeline's FBO mode in JSR-231 beta 4.

This is the last planned beta before the 1.0.0 release of the JSR-231 reference implementation. Please download and try it with your applications and report any stability problems or other bugs as soon as possible. Thanks for all of your support on this long road towards standardization.

I have a project I am working on that uses JInternalFrames to manage several transparent JPanels over a fullscreen GLJPanel. I have no problems with the z-ordering after setting the GLJPanel opaque to false, but the performance is at a slug's pace (about 5 fps).

To try and rule out some causes, I switched to a GLCanvas and was able to achieve my 60 fps, but of course due to the fact that it is a heavyweight component, it draws over everything.

I have ran your JRefract interoperability demo and see no difference in performance with or without the iteroperability enabled. I've been pulling out hair over this issue, any help would be greatly appreciated.

The same results are consistent with our entire development team. We are all developing on WIndowsXP SP2 using Netbeans 5.0. We have linked in the latest JOGL builds and are using Mustang b87.

The release of 1.0.0 is imminent, probably within the next week or two. All of the materials have been submitted to the Program Management Office of the JCP and we are just waiting to hear back from them.

The final release of JSR-231 1.0.0 has been posted today, September 14, 2006!

The binaries and source code for the reference implementation of the specification are available in the Documents and Files section of the JOGL home page. The on-line JOGL demos have been updated to use the 1.0.0 release of the code. An extension JNLP file which will permanently point to the 1.0.0 release is now available at

The "current" extension JNLP file listed in the JOGL User's Guide is still available and is the best way to ensure your Java Web Started application is always using the most recent release.

We will continue to develop JOGL; expect a follow-on 1.0.1 release shortly (containing no API changes) which will incorporate bug fixes made since the final approval ballot was submitted.

I would like to thank you all; as members of the JOGL community your feedback on the APIs and implementation has driven the development of the project for the past three years. I look forward to continuing to work with you to evolve the project.

API changes are done under a Maintenance Update of the JSR which is a much lighter-weight process not going through an expert group. We will probably start this process for the OpenGL 2.1 headers shortly. The nightly builds of JOGL can continue to evolve very quickly and are considered the "unofficial" builds of the RI. The version strings in these builds will be e.g. "1.0.1-pre".

It does mean that we won't be making any incompatible API changes going forward. If we decide to rethink something like the GLCapabilitiesChooser mechanism we will preserve the existing one and add the new API alongside it.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org