JSR-231 1.1.1a Released

Right. It doesn’t happen on cards that supports at least OpenGL 1.5.

The regression appeared in JOGL 1.1.1 rc5 but with another symptom, the JVM crashes and produces a log file (please find this file enclosed below). The exception in TextRenderer.endRendering() is reproducible in JOGL 1.1.1 rc6, JOGL 1.1.1 rc7, JOGL 1.1.1 rc8 and the final stable version of JOGL 1.1.1. I hope it will help you.

It may come from the introduction of TextureRenderer and Overlay, maybe TextRenderer uses TextureRenderer since rc5, doesn’t it?

How can I fill a bug report for JOGL?

here: https://jogl.dev.java.net/servlets/ProjectIssues

but i think you need to contact ken russel first, to get observer status on the jogl project.
i believe his email is kenneth dot russel at sun dot com

Thanks. I will contact him as soon as possible. I have looked the source code. I have no idea of how to fix it. The only strange thing is that the VBOs are never disabled whereas endRendering() checks if they are disabled.

Please vote here to help me to get some help to solve this bug:
https://jogl.dev.java.net/issues/showvotes.cgi?voteon=356

WWJ, other engines and other games will be penalized by this bug with pre-OpenGL 1.5 versions. People who can’t afford buying more recent graphics cards will be penalized. Can someone help me in fixing this bug? I will try some fixes and I need someone to check if there are no regression for post-OpenGL 1.5 versions.

;D ;D ;D ;D ;D

I have found a workaround!!!

Explicitly unbind the last buffer you use by doing this:
gl.glBindBuffer(GL.GL_ARRAY_BUFFER,0);
Put the line above just before calling beginRendering() or begin3DRendering().

It should not be required except if you don’t use the same mechanism to check if VBO extensions are available… that’s the case of TUER. JOGL tests if OpenGL 1.5 is available and if it can bind a buffer (if there is no exception by using a try catch clause), then it considers that VBO extensions are available. TUER (WWJ and other engines too) uses a finer method. It checks only once if the functions and the VBO extensions are both available. Then, under OpenGL 1.4, if ARB VBO extensions are available, TUER uses VBOs and JOGL doesn’t use them and ignores the case of someone using VBOs. Here is the modification to do to allow this to work in all cases:

in com.sun.opengl.util.j2d.TextRenderer:

private boolean bindBufferAvailable;

public TextRenderer(Font font, boolean antialiased,
boolean useFractionalMetrics, RenderDelegate renderDelegate,
boolean mipmap){
GL gl = GLU.getCurrentGL();
bindBufferAvailable = gl.isFunctionAvailable(“glBindBufferARB”) || gl.isFunctionAvailable(“glBindBuffer”);


}

in com.sun.opengl.util.j2d.TextRenderer$Pipelined_QuadRenderer.drawVertexArrays()


if (usingVBOs) {
gl.glBindBuffer(GL.GL_ARRAY_BUFFER,
mVBO_For_ResuableTileVertices);
gl.glBufferSubData(GL.GL_ARRAY_BUFFER, 0,
mOutstandingGlyphsVerticesPipeline * kSizeInBytes_OneVertices_VertexData,
mVertCoords); // upload only the new stuff
gl.glVertexPointer(3, GL.GL_FLOAT, 0, 0);
} else {
if(bindBufferAvailable)
gl.glBindBuffer(GL.GL_ARRAY_BUFFER,0);//unbinds any already bound buffer

gl.glVertexPointer(3, GL.GL_FLOAT, 0, mVertCoords);
}

N.B: do the same for texture coordinates
A better way to solve this problem would be to use a finer mechanism to check if VBOs can be used.

Hi!

A better fix would be to add a method called void setUseVertexBufferObjects(boolean useVertexBufferObjects) in TextRenderer to allow programmers to force the use of VBO even though JOGL assumes they should not been used. Could it be added in JOGL 1.1.2?

As nobody seems to be interested in helping me, I will submit several fixes and the people responsible of it will choose the better one.

I was having the same issue! Thanks for pointing it out.

Hi!

I’ve got a good news! I’ve found a quite good fix for the issue 356. It is very close to the first suggestion I made. The impact on the frame rate is tiny if you use VBOs whose element count is under GL_MAX_ELEMENTS_VERTICES. I’m going to submit the file in a few minutes. Please add it into the nightly build if possible. Thank you.

Hi!

I know how to submit a bug but I don’t find how to submit a RFE (request for enhancement). I would like to find JOGL packaged in a RPM because it would allow games using JOGL to be packaged in RPM too and then to be added in some Linux distributions. I found some RPM but they depend on GCJ and TUER works nor with GCJ neither with OpenJDK, only with Sun JVM.

You might want to get in touch with the JPackage (http://www.jpackage.org/) people and see if they want to help out.

I looked at a JOGL package on JPackage and I didn’t find it but maybe they could help me, it is an excellent idea. It would be fine if I could help many authors of Java open source games to put their games into some standard Linux distributions :smiley:

Someone else suggested to add a timer in JOGL and it is an excellent idea as Windows is particularly not accurate (Linux has an accurate system timer).

Bad news. The fix causes a crash of the JVM after 99 seconds on Mesa 6.5, glBindBufferARB seems very unstable when used to unbind a buffer. I’ve had to use the older implementation of TextRenderer to solve the problem.

Can you confirm that Jogl works with Java 6 on Mac OS X? I’ve got a machine with Java 5/32-bit, Java 5/64-bit, and Java 6/64 bit. The Gears demo won’t launch under 6. Exception stack trace follows.

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.javaws.Launcher.executeApplication(Launcher.java:1301)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1239)
at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1086)
at com.sun.javaws.Launcher.run(Launcher.java:105)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.lang.UnsatisfiedLinkError: no jogl in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1753)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at com.sun.opengl.impl.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:189)
at com.sun.opengl.impl.NativeLibLoader.access$000(NativeLibLoader.java:49)
at com.sun.opengl.impl.NativeLibLoader$DefaultAction.loadLibrary(NativeLibLoader.java:80)
at com.sun.opengl.impl.NativeLibLoader.loadLibrary(NativeLibLoader.java:103)
at com.sun.opengl.impl.NativeLibLoader.access$200(NativeLibLoader.java:49)
at com.sun.opengl.impl.NativeLibLoader$1.run(NativeLibLoader.java:111)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.opengl.impl.NativeLibLoader.loadCore(NativeLibLoader.java:109)
at com.sun.opengl.impl.macosx.MacOSXGLDrawableFactory.(MacOSXGLDrawableFactory.java:53)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:108)
at javax.media.opengl.GLCanvas.chooseGraphicsConfiguration(GLCanvas.java:520)
at javax.media.opengl.GLCanvas.(GLCanvas.java:131)
at javax.media.opengl.GLCanvas.(GLCanvas.java:90)
at javax.media.opengl.GLCanvas.(GLCanvas.java:83)
at demos.gears.Gears.main(Gears.java:19)
… 9 more

Are you sure you installed it correctly? JOGL 1.1.1 has been tested under Mac OS X 10.5 update 2 with the Apple’s JDK 1.6.0_07 on a 64 bits Intel machine with TUER (alpha version). As it is really hard for me to find people to test it again Mac, I cannot try again.

Do you mean is Java 6 installed correctly, or JOGL? In the first case, I have done no customization of the Apple install process, so it’s a reasonable assumption that the first answer is yes. In the second case, the Gears demo is being launched through Java Web Start, which is intended to deploy all required jars, so whether it is installed correctly could only be answered by whomever wrote the jnlp file. Since the exception being thrown refers to a native library, I would suspect that part of the jnlp. The first one loads the second one below.

<?xml version="1.0" encoding="utf-8"?>



JOGL Gears Demo
Sun Microsystems, Inc.

Gears Demo
Brian Paul’s Gears demo ported to Java and JOGL.

<resources>
  <j2se href="http://java.sun.com/products/autodl/j2se" version="1.4+"/>
  <property name="sun.java2d.noddraw" value="true"/>
  <jar href="jogl-demos.jar" main="true"/>
  <jar href="jogl-demos-util.jar" />
  <extension name="jogl" href="http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp" />
</resources>

Referenced jogl.jnlp:

Java Binding to the OpenGL API Sun Microsystems, Inc. Java Binding to the OpenGL API - JSR-231 Current Build Java programming language binding to the OpenGL 3D graphics API. (Current build of JSR-231 APIs)

Hi. You should install JOGL directly and relaunch this demo to compare. If it works, it means that something is wrong in the JNLP file.

JSR-231 1.1.1a has been posted today, June 18, 2009.

This is a patch release correcting a buffer overrun. Thanks to the Microsoft Vulnerability Research team for pointing out this issue.

This update is completely compatible with the previous JSR-231 1.1.1 release. An extension JNLP file which will permanently point at this release is available at


http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.1a/webstart/jogl.jnlp

The preferred “current” extension JNLP file for the JOGL 1.x releases has changed because of the upcoming change to the JOGL 2 APIs:


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

The previous jsr-231-webstart-current link will live for the indefinite future, but the link above is now the preferred one.

Due to security concerns, all Java Web Start binaries for all previous releases of JOGL have been changed to point to the 1.1.1a binaries, and the webstart zip archives like jsr-231-1.1.1-webstart.zip have been removed. If you have re-hosted the signed JOGL binaries on your own web server, we recommend updating to the 1.1.1a version.

Please post if you run into any problems with this release. More to come soon regarding JOGL 2.

JOGL 2.0 Release Candidate 11 has been posted November 1, 2012.

You can find the change logs here.

Notable changes:
Dropping X11InitThreads()
Transparent FBO drawable
Full OSX support [CaLayer, Java7, GL3.2, …]
PMVMatrix / ProjectFloat / FloatUtil fixes and enhancements
Enhanced fixed function utils: FixedFunctionPipeline / ImmModeSink
NEWT KeyEvent handling
NEWT BCM VC IV (Raspberry Pi) support
Unit Tests: Covering all drawable configurations
API Doc Enhancements

An extension JNLP file which will permanently point at this release candidate is available at


http://jogamp.org/deployment/v2.0-rc11/jogl-all-awt.jnlp

WTF this is almost 3.5 years old!