JSR-231 1.1.1a Released

OpenGL Development JOGL Development
#1

JSR-231 1.1.0 Release Candidate 1 Released

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:


<extension name="jogl" href="http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp" />

The following changes have been made since JSR-231 1.0.0:

[] 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!

#2

Thank You. :slight_smile:
Glad to see GL and so forth are finally added and buffer performance has increased.

I really do love JOGL, it’s a personal pet and obsession of mine.

#3

Lovely to see you decided to supply Windows x64 binaries that is a real time saver for us… :slight_smile:

Matt.

#4

nice work dude! rockin work mate

#5

great work Ken!

i cant wait for that feature! :smiley: do you have any estimates on a release date for this? :slight_smile:

thanks!

#6

It’s ready. :slight_smile: Please see this thread. The classes are already present in the nightly builds.

#7

JSR-231 1.1.0 Release Candidate 2 has been released on January 23, 2007. The following changes have been made since 1.1.0 release candidate 1:

[] 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.

#8

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.

#9

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.

Best regards,
Michal Pociecha-Los

#10

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.

#11

hello, i was trying to update to RC2 but i experienced texture issues when setting mipmaping to false.

i am reading pngs like this:

Texture tex = TextureIO.newTexture(TextureIO.newTextureData(ImageIO.read(new File(“loading.png”)), false));

but the outcoming texture is either completely white or scrambled. looks like it is somehow interlaced…
however, if i turn on mipmapping like this:

Texture tex = TextureIO.newTexture(TextureIO.newTextureData(ImageIO.read(new File(“loading.png”)), true));

everything seems to work.

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

[tr] [td][/td] [td]1.0[/td] [td]1.1 RC2[/td][/tr]
[tr] [td]newTextureData[/td] [td]10.000.000[/td] [td]15.000[/td][/tr]
[tr] [td]newTexture[/td] [td]2.000.000[/td] [td]30.000.000[/td][/tr]

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

thanks.

#12

Hi Ken, and thanx for your fast answer.

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?

Best regards,
Michal.

#13

Hi, Ken.

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.

Regards,
Michal.

#14

No problem. As a hint, here’s a generic way to copy an arbitrary (direct or non-direct) FloatBuffer into a ByteBuffer:


  FloatBuffer src;
  ByteBuffer dst;
  dst.asFloatBuffer().put(src);

To handle arbitrary Buffers you’ll just need a helper routine similar to that in the GlueGen runtime which tests the type of the incoming Buffer and does the appropriate casts.

#15

Thanx Ken.

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.

Regards,
Michal

#16

Sounds like great results. I hope you’ll consider making your project open source and posting here about its availability.

#17

Is anyone else getting “Hello World” being continually being written to the Java console? I don’t
think this is my code. I’m using:

<extension name="jogl" href="http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp"/>

in my JNLP.

yottzumm

#18

This println is definitely not in the JOGL code. Do a Find in Files in your project or check the other libraries you’re using.

#19

JSR-231 1.1.0 Release Candidate 3 has been posted on February 14, 2007. The following changes have been made since release candidate 2:

[]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.

#20

thanks for the update Ken! i am very glad that the jogl project is so actively developed and new releases come at a regular basis.

i tried the RC3 out, and in my project, the performance in the TextureIO.newTexture() functions still seems worse than in the 1.0.0 release, because i do a lot of texture uploading at runtime.

i posted the comparisons here:
http://www.java-gaming.org/forums/index.php?topic=15594.msg125954#msg125954

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