JSR-231 1.1.0 Release Candidate 1 has been posted on December 22, 2006. This is not an "official" release of JSR-231, but a pre-release of Sun's reference implementation including planned specification updates. The binaries and source code are available at the link above. The on-line JOGL demos have been updated to use this release of the code. The current extension JNLP listed in the JOGL User's Guide has also been updated:

The glext.h and associated header files JOGL uses have been updated to OpenGL 2.1 with NVidia's GeForce 8 series extensions. The new functions are available as methods in the GL interface.

The JOGL applet launcher now supports deployment of applets which use both OpenGL for 3D graphics via JOGL as well as OpenAL for spatialized audio via JOAL. It now prompts the user on Windows platforms to allow it to enable the -Dsun.java2d.noddraw=true system property for best robustness. It has been updated for the changes in the GlueGen runtime classes and native library structure. Some bugs have been fixed, some of which were preventing different JOGL-based applets from being deployed from the same codebase. The documentation and on-line examples have been updated as well.

The developer build bundles have been changed to zip archives, so instead of having to download multiple jars, you can now just download the zip archive for your particular platform. The new zip archives are versioned with the build date.

The source distribution now contains the generated sources like GL.java, GLU.java, etc. for more convenient use in IDEs.

The chosen GLCapabilities are now exposed from the GLDrawable via GLDrawable.getChosenGLCapabilities(); this functionality works on all platforms even in cases where the GLCapabilitiesChooser is not supported, and attempts to provide correct answers so programs can make decisions based on the results.

The native code for the "DRI hack" (to support the open-source DRI drivers on Linux and other X11 platforms) has been removed; JOGL now uses the GlueGen NativeLibrary class for this purpose.

The GlueGen runtime classes have been removed from jogl.jar. These have been factored out into gluegen-rt.jar and are referenced by both the JOGL and JOAL projects.

Thanks to John Burkey some optimizations have been made to the buffer object-related validity checks in glVertexPointer, etc. as well as a buffer size query that was being made in the glMapBuffer implementation. This improves performance for applications performing a lot of VBO- or vertex array-based rendering, in particular with the multithreaded OpenGL implementation on Mac OS X.

Various bug fixes and robustness improvements were made to the GlueGen runtime and JOGL implementation.

Windows/AMD64 binaries, including the JOGL Cg binding, are now supplied.

Worked around breakage of JOGL with 5.0u10; see Sun bug IDs 6504460 and 6333613.

More changes are planned in future release candidates. There are some RFEs including adding a copyContext method (which will impact the specification) which will be addressed. Previously announced functionality like text rendering support will be added in future builds.

Thanks go in particular to Travis Bryson from Sun for pushing through a build at the last minute.

Please post here with any questions or comments about the new build. Happy holidays!

The TextureIO implementation has been changed to no longer copy the data associated with BufferedImage TextureData objects. Instead, the necessary vertical flip is now implemented by flipping the texture coordinates vertically.

An API for updating a sub-image of a Texture object from a sub-portion of a TextureData object has been added.

Three new Java 2D interoperability classes are now included in the com.sun.opengl.util.j2d package: TextureRenderer, Overlay, and TextRenderer. Based on community feedback, the TextureRenderer and TextRenderer classes have been expanded to make it easier to draw 2D rendering results and text in 3D.

Four new text-related demos are now included on the JOGL demos web page.

Added a GLContext.copy() operation based on community feedback.

Reliability improvements when a makeCurrent() operation fails and a GLException is thrown.

Reliability improvements to the so-called "DRI hack" class; this has been confirmed as once again working with ATI's proprietary drivers on Linux and should also work better with NVidia's drivers.

Robustness improvements to the JOGLAppletLauncher when the JOAL classes are not present on the web server.

Based on community discovery, added documentation to JOGLAppletLauncher on why JOGL applets may run slowly in the Mozilla / Firefox browsers (root cause: the Talkback agent).

Please try this release with your applications and post feedback here. We plan to submit these APIs to the JCP soon; the official release of JSR-231 1.1.0 should follow roughly six weeks afterward.

Also, thanks to the staff at O'Reilly, Pack200 compression is now enabled for JOGL. If you are running with a Java SE 5.0 or later Java Web Start or Java Plug-In client, you will automatically download the pack200-gzip compressed versions of the jar files, which are considerably smaller than the versions compressed with normal zip compression. We're additionally going to look into ways to reduce the size of jogl.jar even further.

I don't know if it's the right place to put this message, but I could not find a better one.

I'm concerned about the decision to map (void*) type from C to java.nio.Buffer in Java. One of the methods using that mapping is glTexImage2D(). I'll try to describe the problem I have with it.

I'm working on a concrete implementation of GL interface, which instead of calling OpenGL library functions directly, would send the data to output stream, redirecting the actual rendering to the process (or any kind of input stream reader) sitting at the other end of the output stream.

The story behind this idea is very short. What I wanted to achieve is to perform rendering in Java, using an abstraction of OpenGL provided by GL interface. But the goal was to redirect actual rendering to different process (in my case it's a Cocoa application on Max OS X).

The problem I have is simple: there are a couple of methods having java.nioBuffer argument. What I need to do, is send the content of the buffer to the WritableByteChannel. The problem is, that it can not be done in general, because the write() method on the WritableByteChannel takes ByteBuffer as a parameter. There's no way in Java to wrap a Buffer into ByteBuffer, or to read the content of the buffer in general. The only thing which I can do, is try to downcast an instance of Buffer to ByteBuffer, and pray that it really is an instance of ByteBuffer.

I'm aware of the fact, that from the JOGL's point of view, it does not matter which kind of buffer is passed to the gl method, because it's possible to get access to the buffer content using JNI. But using pure Java it's not possible. That's why it makes the GL interface flawed in that are, because it's not possible to implement it without using JNI.

What is your view on that issue? Has it already been discussed somewhere else? I'm waiting for your response.

From the standpoint of the API, mapping void* to Buffer reduces the number of overloadings at the potential expense of more code in the back end. You can look at the source code for the run-time helper class com.sun.gluegen.runtime.BufferFactory in the GlueGen workspace to see some of the extraction routines that are necessary behind the scenes to deal for example with direct vs. non-direct Buffers. The JOGL implementation occasionally has to down-cast Buffer to e.g. ByteBuffer or FloatBuffer in order to perform certain operations.

Since WritableByteChannel only accepts a ByteBuffer as argument, if the incoming Buffer is of a different type I think you'll have to copy the data into a temporary ByteBuffer before writing it out. That would be true even if the API exposed void* as multiple overloadings such as ByteBuffer, IntBuffer, FloatBuffer, etc.

edit: and i hate to say it, but to me it seems that performance is worse with RC2 than with jogl1.0.0. especially the newTexture() functions seem to take longer. i am creating and updating textures a lot during runtime, so it happens really often, that the game lags because of this.i cant prove this with facts, its just a personal observation.

edit2:ok, i have been testing the TextureIO.newTextureData and TextureIO.newTexture() functions using System.nanoTime()here are the approximate results in nanoseconds

1.0

1.1 RC2

newTextureData

10.000.000

15.000

newTexture

2.000.000

30.000.000

since the newTexture functions has to be run in the GL-thread, i suspect this is the reason for the lags.

First of all, I'd like us to take a little bit deeper look at the Java NIO API.

The first observation is, that the Java NIO API not provide any method to copy the content of buffer of "different" type to a ByteBuffer. In other words, having an instance of, let's say, FloatBuffer it's not possible to create a ByteBuffer out of it, using Java NIO API. In that light, it's not possible to write generic method in Java, which would write the content of, let's say, FloatBuffer (or any other kind of buffer different than ByteBuffer) to a Channel.

The second observation is, that the only way to create an instance of buffer of "different" type is to create a wrapper on an instance of ByteBuffer. In example, to create an instance of FloatBuffer, you MUST first create an instance of ByteBuffer, and then wrap it with FloatBuffer using ByteBuffer.asFloatBuffer() method.

That's why I think, that using ByteBuffer, instead of Buffer, as an argument in the mentioned methods in GL interface would be a sligtly better solution. I believe that it would simplify the native code a little bit (no need to downcasting), and increase the flexibility of GL interface, because it would make it possible to implement it purely in Java, in a complete way.

I love the idea of having a GL interface, because it provides an abstraction of GL to the Java developer. Having that, it's possible to implement the GL interface in any, custom way. Unfortunalety, because the java.nio.Buffer was used in a couple of methods, it's not possible to implement those methods purely in Java.

Final thought. Isn't it some kind of a hint, that there's no generic WritableChannel class with write(Buffer) method to write content of any buffer? What we have, is only WritableByteChannel with write(ByteBuffer) method. Maybe the GL interface should go in the same direction? Or maybe the Java NIO API should be redesigned/extended to have a generic WritableChannel class with write(Buffer) method?

I just wanted to apologize for my last post, because it was a complete junk.I've just missed few things while reading the Javadoc fpr Java NIO, and that's why I was convinced,that it was not possible to write data from, let's say, FloatBuffer to WritableByteBuffer.

I'm still not sure how to write the content of FloatBuffer in case it's not backed by a float[] array,but I'll try to investigate it on my own, rather than taking your valuable time.

This is the part which I have missed: the FloatBuffer.put(FloatBuffer) method.

With that knowledge, the project I'm currently working on, to send OpenGL rendering over input/output streams, is almost finished. As a proof of concept, I redirected the OpenGL rendering from my sample Java application to native Max OSX application through UNIX pipes.

The result was awesome! The overhead of pushing the data through the stream was insignificant, and the animation seemed to run as smooth as in Java. As a point of reference I'd like to mention, that in Java I used GLCanvas, and in Cocoa I used NSOpenGLView.

One of the most noticable side-effects was, that in case of the Java application I used for testing (simple ZX Spectrum emulator), it ran much smoother when the rendering was sent over the stream. This may be due to the fact, that the actual rendering was delegated to the separate UNIX process, and was not performed within the same process in separate Java thread.

Thanks for your help Ken, and I'm waiting impatiently for final 1.1.0 Release.

Support for two new applet parameters, jogl.silent.noddraw.check and jogl.disable.noddraw.check, has been added to the JOGLAppletLauncher. Please see the JOGLAppletLauncher javadoc.

A new RenderDelegate interface has been added to the TextRenderer class, providing more control over how the bitmapped text is rendered. A new CustomText demo has been posted on the JOGL demos website.

Minor bug fixes and other improvements.

Please try this new release and post any comments here. The APIs covered by the JSR-231 specification (javax.media.opengl, javax.media.opengl.glu) have been sent to the JCP and should be approved sometime in March. We will probably do another release candidate build before then with a couple of additional bug fixes.

can you confirm, that maybe more work is done now in the newTexture() functions, which has been done in the newTextureData() functions before?

There should be less work being done overall for BufferedImage-based (including ImageIO-based) texture loading. The ImageIO subsystem is used to handle file formats like PNG. A lot of work used to be done in newTextureData() which is no longer done, but it shouldn't have necessarily been replaced with work in newTexture(), unless your input data was a TYPE_CUSTOM BufferedImage or other format which doesn't map to a native OpenGL texture format. If it is, you can circumvent this work by manually converting your loaded BufferedImage into a format supported natively by OpenGL before passing it to newTexture(). TYPE_INT_RGB or TYPE_INT_ARGB are good bets. You can look at the TextureData.createFromCustom() method for a hint on how to do this.

After the update to 1.1.0 RC3 I had to do a "javaws -uninstall" in order for JOGL to work again through webstart, otherwhise I got an "no jogl found in java.library.path" exception in all webstart JOGL apps (including the demos on jogl.dev.java.net).

I don't know why I had to do this, but I post it here in case others have the same problem. I use Windows Vista and Java 6. By the way, it is sad that the javaws from Java 6 has no GUI any more, I found it useful.

A lot of work used to be done in newTextureData() which is no longer done, but it shouldn't have necessarily been replaced with work in newTexture(), unless your input data was a TYPE_CUSTOM BufferedImage or other format which doesn't map to a native OpenGL texture format.

yes, unfortunately they are of type custom. so if i work out a way to convert my CUSTOMs to TYPE_INT_ARGB wouldnt this result in about the same things that are done in the TextureData.createFromCustom(BufferedImage image) function?

After the update to 1.1.0 RC3 I had to do a "javaws -uninstall" in order for JOGL to work again through webstart, otherwhise I got an "no jogl found in java.library.path" exception in all webstart JOGL apps (including the demos on jogl.dev.java.net).

I saw this problem on a couple of machines but in one case it seemed to fix itself. At the time I assumed that it was due to the timestamps changing on the files coming back from the web server. On the other machine the hard disk was failing and I assumed that was the root cause. If people continue to have problems please post.

yes, unfortunately they are of type custom. so if i work out a way to convert my CUSTOMs to TYPE_INT_ARGB wouldnt this result in about the same things that are done in the TextureData.createFromCustom(BufferedImage image) function?

It will at least allow the conversion work to be done in a background thread instead of your rendering thread. The conversion work had to be moved to the point at which the OpenGL texture was created or updated in order to honor the new guarantees that updates to the image's contents will be reflected in the contents of the OpenGL texture.

Also, thanks to the staff at O'Reilly, Pack200 compression is now enabled for JOGL. If you are running with a Java SE 5.0 or later Java Web Start or Java Plug-In client, you will automatically download the pack200-gzip compressed versions of the jar files, which are considerably smaller than the versions compressed with normal zip compression. We're additionally going to look into ways to reduce the size of jogl.jar even further.

Ken, is it possible to have access to these signed p200 gzipped files from the download section of jogl ?

I'd like to put them on my web server for JOGLAppletLauncher usage, and the best way to do that seems to get them from an official distribution, like the non p200 ones.

I've updated the jogl-1.1.0-rc3-webstart.zip archive with the .pack.gz versions of jogl.jar, jogl-demos.jar, and jogl-demos-util.jar. There wasn't any gain to be had by Pack200 compressing the other jar files (including the native jar files), at least as far as I found. We'll try to remember to include these in this zip bundle in the future. For the record, though, if you just run Pack200 on the (signed) jogl.jar in the webstart archive, you'll get the same result as these .pack.gz files.

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