[JOGL-382] Crash using MESA on virtualbox Created: 25/Feb/14  Updated: 25/Feb/14

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: eban Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OpenSUSE 13.1, with VBox 3D acceleration enabled. Mesa version is 9.2.3-61.9.1.x86_64



 Description   

Running the test.sh crash if we using jogl version 2.1.3 or 2.1.4 but works fine with 2.1.2



 Comments   
Comment by eban [ 25/Feb/14 ]

Sorry, wrong bugtracker, please disregard/delete this ticket





[JOGL-381] no jogl in java.library.path exception Created: 09/Nov/11  Updated: 05/Dec/11

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ranu Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I am having a problem in running JOGL inside java applet.Can anyone please explain the exact procedure to do this?



 Comments   
Comment by dekken [ 29/Nov/11 ]

In case you haven't already found a solution, it's probably because you are not linking to the jogl/gluegen dll files.
Throw them all in the same directory and use the following command line arg -Djava.library.path=<path/to/dll/files>

If you are using Eclipse:
right click on the Applet file -> Run as -> configuration -> select current (or create new) -> Click arguments tab -> add previous argument to Program args -> run.

Viola.

Comment by ranu [ 05/Dec/11 ]

Thank you for your reply.The problem is am not using Eclipse.I am using Netbeans IDE.And I am binding all the jar files with the java code.I want to run this from the server,i.e, a client will run jogl without this error.How do I do that? where will I keep .dll files for the client?





[JOGL-380] jogl applet now gives security warning Created: 26/Oct/11  Updated: 26/Oct/11

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jcoady Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 7, Chrome web browser, Firefox web browser, IE web browser.



 Description   

JOGL now gives a security warning when used in an applet. It looks like the special security certificate from SUN/Oracle for jogl has expired. The jogl sample from java.net no longer works.

http://download.java.net/media/jogl/demos/www/applettest.html

For all those developers that used JOGL with JNLPAppletLauncher as described in the above webpage, their applets will no longer work. If the security certificate has expired, please sign it again with the special certificate from SUN/Oracle so that the user is not prompted with a security warning for their unsigned applets in a web page that use JOGL.






[JOGL-254] Provide JOGL JPanel bean for NetBeans Created: 30/Nov/06  Updated: 30/Sep/11

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: ophir Assignee: jogl-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 254

 Description   

This would make GUI layout simpler and encourage JOGL adoption.



 Comments   
Comment by kbr [ 01/Dec/06 ]

Could you please provide a pointer to documentation describing what you mean? I
have very little experience both with NetBeans and JavaBeans in general. The
GLJPanel already contains some tests against Beans.isDesignTime() which I
thought were sufficient to make it work in the NetBeans GUI builder.

Comment by ophir [ 01/Dec/06 ]

Sure, it's discussed on this thread:

http://www.javagaming.org/forums/index.php?topic=14053.0

I tried it recently, but it didn't work for me. I don't recall if it was
exactly the same issue as mentioned on the thread. If it would help, I can try
it again, take better notes, and post them here.

Comment by kbr [ 02/Dec/06 ]

Please do try it again and report the results.

Comment by wyadams [ 30/Sep/11 ]

For anyone still reading stuff this far back, and having trouble finding the discussion thread linked above, the new URL seems to be: http://www.java-gaming.org/topics/errors-of-adding-gljpanel-to-jpanel-in-netbeans-s-gui-builder/14053/view.html





[JOGL-377] float overflow Created: 26/Aug/09  Updated: 20/Mar/10  Resolved: 20/Mar/10

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: orace Assignee: jogl-issues
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File test.cpp    
Issuezilla Id: 377

 Description   

If I do :
GL gl = getGL();
printmatrix();
System.out.println("scale -> " + Scale);
gl.glScaled(Scale.getX(), Scale.getY(), Scale.getZ());
printmatrix();
System.out.println("trans -> " + Translation);
gl.glTranslated(Translation.getX(), Translation.getY(), Translation.getZ());
printmatrix();
With big values for scale ans Translation (up to 10e38,ie max_float) I get a lot
of NaN in the matrix.
Does JoGL use float instead of double for the Modelview/Projection matrix ?

PS : (output of the code below)
GL_MODELVIEW :
_________________________________

0.75 0.0 0.0 0.0
0.0 0.75 0.0 0.0
0.0 0.0 1.0 0.0
0.125 0.125 0.0 1.0

---------------------------------
scale -> 0.25, 2.5000000000000003E-46, 0.5
GL_MODELVIEW
_________________________________

0.1875 0.0 0.0 0.0
0.0 0.0* 0.0 0.0
0.0 0.0 0.5 0.0
0.125 0.125 0.0 1.0

---------------------------------
0.0* here we have 0.0 instead of 1.875E-46
trans -> -1.0, -1.0E45, -1.0
GL_MODELVIEW
_________________________________

0.1875 0.0 0.0 0.0
0.0 0.0 0.0 0.0
0.0 0.0 0.5 0.0
NaN NaN NaN NaN

---------------------------------
here we have to mush NaN



 Comments   
Comment by orace [ 01/Sep/09 ]

Created an attachment (id=141)
Test program show that 'native' OpenGL also have overflow 'bugs'

Comment by orace [ 01/Sep/09 ]

This is not a JoGL bug, indeed OpenGL *use* single precision Floating-Point
Computation.

See Opengl 3.1 spec : http://www.opengl.org/registry/doc/glspec31.20090528.pdf
§2.1.1 page 7

A C/C++ programs with OpenGL reproduce the same bug.

Comment by mbien [ 20/Mar/10 ]

set to INVALID since its expected behavior.





[JOGL-379] JOGL 2.0 beta JNLP applets collides with installed JOGL 1.x Created: 22/Oct/09  Updated: 22/Oct/09  Resolved: 22/Oct/09

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: zesharp Assignee: jogl-issues
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 379

 Description   

Hi

JOGL 2.0 beta JNLP applets collides with installed JOGL 1.x in JRE.
The typical output is shown below:

Exception in thread "thread applet-demos.applets.GearsApplet-1"
java.lang.VerifyError:
(class: javax/media/opengl/awt/GLCanvas,
method: chooseGraphicsConfiguration signature:
(Ljavax/media/opengl/GLCapabilities;
Ljavax/media/opengl/GLCapabilitiesChooser;
Ljava/awt/GraphicsDevice Ljavax/media/nativewindow/awt/
AWTGraphicsConfiguration

Incompatible argument to function
at demos.applets.GearsApplet.init(GearsApplet.java:18)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)

This happens because the native function has different signature, but it also
shown a possible issue when mixing old and new DLLs.
I'd like suggest the JOGL 2.0 native binaries(.dll, lib.so) has different
names, to avoid cross loading : JOGL 1.x dlls being loaded by JOGL 2.0 jars,
and vice-versa.

Workaround :
(parcial)
remove JOGL 1.x from JRE6/bin and JRE6/lib/ext



 Comments   
Comment by kbr [ 22/Oct/09 ]

First: the JOGL project has moved to http://kenai.com/projects/jogl. Issues should be reported there and
not on this site.

Installing JOGL into the JRE has never been supported. See
http://download.java.net/media/jogl/doc/userguide/ under "Local installation for development". That
describes the suggested mechanism for developing locally with JOGL.





[JOGL-378] TextureData incorrectly requires GL context Created: 27/Aug/09  Updated: 27/Aug/09

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: qwerty999 Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 378

 Description   

Hi, in JOGL2 there is an issue with creating a TextureData. TextureData for some reason requires the GL
context to be available. But the whole point of having TextureData was to separate texture preparation
from the GL context.

You can see for instance in the class AWTTextureData.java one method requires an open GL context
simply to determine the GLProfile.

GLProfile glp = GLContext.getCurrentGL().getGLProfile();
if (glp.isGL2())

{ ... }

So, calling a method via the TextureIO class such as:

TextureIO.newTextureData(myFile, false, null);

will throw this exception:

Exception in thread "main" javax.media.opengl.GLException: No OpenGL context current on this thread
at javax.media.opengl.GLContext.getCurrentGL(GLContext.java:159)
at com.sun.opengl.util.texture.awt.AWTTextureData.createFromImage(AWTTextureData.java:173)
at com.sun.opengl.util.texture.awt.AWTTextureData.<init>(AWTTextureData.java:102)
at
com.sun.opengl.util.texture.spi.awt.IIOTextureProvider.newTextureData(IIOTextureProvider.java:69)
at com.sun.opengl.util.texture.TextureIO.newTextureDataImpl(TextureIO.java:765)
at com.sun.opengl.util.texture.TextureIO.newTextureData(TextureIO.java:180)






[JOGL-376] jogl failure under VirtualBox 3.0.0 Created: 10/Jul/09  Updated: 20/Jul/09

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: merscwog Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Other


Issuezilla Id: 376

 Description   

Attempting to run jogl under Kubuntu (or ubuntu 64-bit or 32-bit) within
VirtualBox 3.0.0 under Vista 64-bit results in the following stack trace:

OpenGL Warning: XGetVisualInfo returned 0 visuals for 41047640
OpenGL Warning: glXGetFBConfigAttrib for 0x41047640, failed to get XVisualInfo
Exception in thread "main" javax.media.opengl.GLException: glXGetFBConfig(0x801\
1) failed: error code GLX_BAD_ATTRIBUTE
at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfiguration.glXGetFBConf\
ig(X11GLXGraphicsConfiguration.java:350)
at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfiguration.GLXFBConfig2\
GLCapabilities(X11GLXGraphicsConfiguration.java:294)
at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfigurationFactory.choos\
eGraphicsConfigurationFBConfig(X11GLXGraphicsConfigurationFactory.java:196)
at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfigurationFactory.choos\
eGraphicsConfigurationStatic(X11GLXGraphicsConfigurationFactory.java:143)
at com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfigurationFactory.choos\
eGraphicsConfiguration(X11GLXGraphicsConfigurationFactory.java:59)
at com.sun.opengl.impl.x11.glx.awt.X11AWTGLXGraphicsConfigurationFactor\
y.chooseGraphicsConfiguration(X11AWTGLXGraphicsConfigurationFactory.java:118)
at javax.media.opengl.awt.GLCanvas.chooseGraphicsConfiguration(GLCanvas\
.java:700)
at javax.media.opengl.awt.GLCanvas.addNotify(GLCanvas.java:393)
at java.awt.Container.addNotify(Container.java:2578)
at java.awt.Window.addNotify(Window.java:662)
at java.awt.Frame.addNotify(Frame.java:470)
at java.awt.Window.show(Window.java:858)
at java.awt.Component.show(Component.java:1563)
at java.awt.Component.setVisible(Component.java:1515)
at java.awt.Window.setVisible(Window.java:841)
at demos.gears.Gears.main(Gears.java:51)

This was for the simple Gears demo, but it happens for any demo. It might be
considered a VirtualBox bug since glxinfo shows that GLX_SGIX_fbconfig is listed
as an extension.

server glx vendor string: Chromium
server glx version string: 1.2 Chromium
server glx extensions:
GLX_ARB_multisample, GLX_EXT_texture_from_pixmap, GLX_SGIX_fbconfig
client glx vendor string: Chromium
client glx version string: 1.2 Chromium
client glx extensions:
GLX_ARB_multisample, GLX_EXT_texture_from_pixmap, GLX_SGIX_fbconfig
GLX version: 1.3
GLX extensions:
GLX_ARB_multisample, GLX_EXT_texture_from_pixmap, GLX_SGIX_fbconfig

It likely should return a valid value when requesting GLX_RENDER_TYPE (SGI
OpenGL documentation isn't really clear whether it has to or not because the
default is supposed to GLX_RGBA_BIT if not explicitly included as part of an
attribList), but it seems that even if it is not available, as it is not here,
jogl could fall back to assuming GLX_RGBA_BIT.

What's even more strange, is that the rest of the glxinfo shows that it somehow
thinks that rgba is the render type (maybe as the default?). All 64 are
identical except for the ID so I've only shown the information for the first one
of ID 0x21 using both the table and verbose form.

[glxinfo -t]
64 GLXFBConfigs:
Vis Vis Visual Trans buff lev render DB ste r g b a aux dep ste
accum buffers MS MS
ID Depth Type parent size el type reo sz sz sz sz buf th ncl r
g b a num bufs
----------------------------------------------------------------------------------------------------
0x21 0 TrueColor 0 24 0 rgba 1 0 8 8 8 0 0 16 8 0
0 0 0 1 1

[glxinfo -v]
64 GLX Visuals
Visual ID: 21 depth=24 class=TrueColor
bufferSize=32 level=0 renderType=rgba doubleBuffer=1 stereo=1
rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=8
auxBuffers=0 depthSize=16 stencilSize=8
accum: redSize=16 greenSize=16 blueSize=16 alphaSize=16
multiSample=0 multiSampleBuffers=0
visualCaveat=None
Opaque.

Since glxgears works fine, I highly suspect that the jogl version would as well
if it didn't halt because it assumed a GLX FBConfig query on GLX_RENDER_TYPE
would return something other than GLX_BAD_ATTRIBUTE.



 Comments   
Comment by merscwog [ 12/Jul/09 ]

The LWJGL (Lightweight Java Game Library) variant of Gears works just fine,
running at the same time as glxgears no less.

After digging into the X11GLXGraphicsCnofiguration source it's clear that my
conjecture was pretty close to correct.

291 sgoethel 1992 public static GLCapabilities
GLXFBConfig2GLCapabilities(GLProfile glp, long display, long fbcfg, boolean
isMultisampleEnabled) {
292 sgoethel 1919 int[] tmp = new int[1];
293 int val;
294 val = glXGetFBConfig(display, fbcfg, GLX.GLX_RENDER_TYPE, tmp, 0);
295 if (val != GLX.GLX_RGBA_BIT)

{ 296 throw new GLException("Visual does not support RGBA"); 297 }

At line 294, short of catching GLException and parsing the getMessage(), there
isn't any way to continue going on.

Unfortunately, glXGetFBConfig wraps the internals so that you cannot discern
easily why a GLException was thrown. In this case, a GLX_BAD_ATTRIBUTE should
be just fine. It seems that the cleanest solution might be to create a derived
Exception that holds the actual return value so it can be examined by other
code, such as the above snippet.

There are many subsequent calls to glXGetFBConfig, so there might have to be
others that use a default value when GLX_BAD_ATTRIBUTE is returned.

A better solution might be to modify getXGetFBConfigAttrib to take a default
optional return value when GLX_BAD_ATTRIBUTE would otherwise be thrown. That
would remove the need for additional try/catch blocks, and quite clear at any
assumptions that are being made when explicit FGConfigAttrib values are not
available.

Comment by merscwog [ 13/Jul/09 ]

It seems that every invocation of GLX.glXGetFBConfigAttrib() returns
GLX_BAD_ATTRIBUTE.

Any changes that I make to use explicit values (culled directly from glxinfo
output, and force a retFBID) just moves the final failure to the following:

OpenGL Warning: XGetVisualInfo returned 0 visuals for 40c35090

OpenGL Warning: glXGetFBConfigAttrib for 0x40c35090, failed to get XVisualInfo
[Repeated 63 times with different 0x4c????? numbers]

Exception in thread "main" javax.media.opengl.GLException:
javax.media.nativewindow.NativeWindowException: Unable to select oneof the
provided GLCapabilities
at
com.sun.opengl.impl.x11.glx.X11GLXGraphicsConfigurationFactory.chooseGraphicsConfigurationXVisual(X11GLXGraphicsConfigurationFactory.java:285)
[Line 285 is not quite correct, but it's whether the NativeWindowException is
caught and re-thrown as a GLException]

This is really starting to look like a native library access issue, but it could
still be something very unique to VirtualBox.

At least it is easy to replicate the error. Unfortunately, I no longer have the
experience nor time necessary to do further lower-level debugging.

Comment by sgoethel [ 16/Jul/09 ]

The funny thing is that GLX.glXChooseFBConfigCopied(..) seems to return
something, if it wouldn't, we would fall back to the XVisual based configuration
without the GLX FBConfig way.
The latter is necessary for everythin >= GL3.0 and for PBuffer as well.

X11GLXGraphicsConfigurationFactory.java line 201
X11GLXGraphicsConfigurationFactory.java line 148 of
http://kenai.com/projects/jogl/sources/jogl-git/content/src/jogl/classes/com/sun/opengl/impl/x11/glx/X11GLXGraphicsConfigurationFactory.java?rev=88cc61ba1b5bb874ca9b2a172f7dae187f0f3b17

So what we could do here is to test this VirtualBox OpenGL 'bug' for GLX
FBConfig beforehand, and then fall back to the XVisual code rigth away.

Anybody willing to test this ? (I don't use VirtualBox, but Linux/KVM only).

However .. it looks like this is a VirtualBox issue, and I doubt that either
glxgears nor LWGLJ utilize GLX FBConfig ..
Since all operation on the FBConfig ID failed in your thorough test,
I would say we should catch it's failer as described above as a workaround.

Cheers, Sven

Comment by merscwog [ 16/Jul/09 ]

So, I forced it to use only chooseGraphicsConfigurationXVisual() and then
further forced it to use the first XVisualInfo that it received because it was
still failing at:
chosen = chooser.chooseCapabilities(capabilities, caps, recommendedIndex);

I eventually get a black square not quite centered around a swing panel behind
it and the below debug output.

requested GLCapabilities[Capabilities[Red: 8, Green: 8, Blue: 8, Alpha:
0, Opaque: true], GL profile: GLProfile[GL2/GL2], DoubleBuffered: true, Stereo:
false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 0, Red Accum: 0,
Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false, Num samples:
0, PBuffer-FloatingPointBuffers: false, PBuffer-RenderToTexture: false,
PBuffer-RenderToTextureRectangle: false],
chosen GLCapabilities: GLCapabilities[Capabilities[Red: 8, Green: 8,
Blue: 8, Alpha: 8, Opaque: true], GL profile: GLProfile[GL2/GL2],
DoubleBuffered: true, Stereo: true, HardwareAccelerated: true, DepthBits: 16,
StencilBits: 8, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16,
Multisample: false, Num samples: 0, PBuffer-FloatingPointBuffers: false,
PBuffer-RenderToTexture: false, PBuffer-RenderToTextureRectangle: false]
FunctionAvailabilityCache.Version.<init>: java.lang.NullPointerException
GL_VENDOR: null
GL_RENDERER: null
GL_VERSION: null

What is most odd are the values in the GLProfile since they don't match what
come out of glxinfo. I have no idea where it is getting the Accum values of 16,
and the stereo of true, among some other differences. The requested GLProfile
is quite close to the actual values put out by glxinfo.

Comment by sgoethel [ 19/Jul/09 ]

Sorry .. but Swing will utilize a PBuffer,
which itself needs GLX FBConfig.
I assume plain GLCanvas or the new NEWT works without GLX FBConfig
then ..

Comment by merscwog [ 20/Jul/09 ]

I can get demos.es2.RedSquare to run using NEWT, and using an application that
uses GLCanvas, I can at least get to a black screen without any errors (it's not
fully working due to GL_EXT_texture_compression_s3tc not being exposed by
VirtualBox proxy OpenGL driver (it's clearly available in the underlying driver)





[JOGL-375] glBlitFramebufferEXT fails when used on OS X with GLJPanel Created: 14/Jun/09  Updated: 14/Jun/09

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: bsder Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh


Attachments: Java Archive File JOGLHello.jar     Text File renderbufferblit.c    
Issuezilla Id: 375

 Description   

I was trying to use glBlitFramebufferEXT to copy an offscreen FBO to the main
screen. It fails when used on a GLJPanel. With the attached program, it
creates a panel with part blue and part red when it should be all red.

This is verified to be a JOGL issue with OS X specifically. The same code on OS
X as a C program works, so it's not specific to the ATI X1600 drivers. The same
JOGL code under Ubuntu Jaunty works with Mesa software rendering and the normal
jogl package so it's not likely to be a bug in my program.

In addition, if you change the GLJPanel to a GLCanvas, things work as expected.



 Comments   
Comment by bsder [ 14/Jun/09 ]

Created an attachment (id=139)
JOGL program to toggle glBlitFramebufferEXT bug

Comment by bsder [ 14/Jun/09 ]

Created an attachment (id=140)
C equivalent program to validate correctness





[JOGL-374] GL.GL_CLIENT_ALL_ATTRIB_BITS should be type int Created: 13/May/09  Updated: 14/May/09

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kitfox Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 374

 Description   

GL.GL_CLIENT_ALL_ATTRIB_BITS is currently type long. It should be type int.



 Comments   
Comment by kbr [ 13/May/09 ]

The use of long for this value is deliberate because of the lack of unsigned integer values in the Java
language. GlueGen automatically picks the next larger type when the sign bit is set, as in this value. I
don't remember exactly when we made the change to GlueGen but I am pretty sure it was motivated by
incorrect glue code generation for some set of C APIs, possibly OpenGL APIs. There is no plan to change
this unless there is a strong reason to do so.

Comment by kitfox [ 14/May/09 ]

Well, right now you can't pass it to GL.glPushClientAttrib(), which only accepts
integers. I presume that casting it to int would chop off some important bits.





[JOGL-373] cgSetCompilerIncludeCallback is missing Created: 01/May/09  Updated: 01/May/09

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kitfox Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 373

 Description   

The methods

CgGL.cgSetCompilerIncludeCallback
CgGL.cgSetCompilerIncludeString

are missing from the CgGL implementation. This makes it very difficult to
combine Cg shaders which use common components.

Would you be able to extend the spec to include these important methods?



 Comments   
Comment by kbr [ 01/May/09 ]

We'll need to upgrade to a more recent version of Cg as well as either add support to GlueGen for callbacks
or write manual glue code for these methods. Not completely trivial.





[JOGL-372] glDrawElementsInstancedEXT has no VBO version Created: 01/May/09  Updated: 01/May/09

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kitfox Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 372

 Description   

According to the OpenGL docs, the method

glDrawElementsInstancedEXT

is only valid when using VBOs. However, JOGL only provides an immediate mode
version of this method. For this method to be useful, it's signature needs to
be changed to use VBOs instead of being passed a buffer.






[JOGL-365] Bug on javax.media.opengl.glu.GLU.gluBuild2DMipmaps Created: 09/Dec/08  Updated: 13/Apr/09

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: brainbr Assignee: jogl-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Attachments: Java Source File Mipmap.java     Java Source File ScaleInternal.java     PNG File tick_hor_major.png    
Issuezilla Id: 365

 Description   

Exception in thread "main" java.nio.BufferUnderflowException
at java.nio.Buffer.nextGetIndex(Buffer.java:474)
at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:117)
at
com.sun.opengl.impl.mipmap.ScaleInternal.scale_internal_ubyte(ScaleInternal.java:253)
at
com.sun.opengl.impl.mipmap.BuildMipmap.gluBuild2DMipmapLevelsCore(BuildMipmap.java:535)
at com.sun.opengl.impl.mipmap.Mipmap.gluBuild2DMipmaps(Mipmap.java:762)
at javax.media.opengl.glu.GLU.gluBuild2DMipmapsJava(GLU.java:1526)
at javax.media.opengl.glu.GLU.gluBuild2DMipmaps(GLU.java:1582)
at com.sun.opengl.util.texture.Texture.updateImage(Texture.java:523)
at com.sun.opengl.util.texture.Texture.updateImage(Texture.java:381)
at com.sun.opengl.util.texture.Texture.<init>(Texture.java:182)
at com.sun.opengl.util.texture.TextureIO.newTexture(TextureIO.java:445)
at com.sun.opengl.util.texture.TextureIO.newTexture(TextureIO.java:465)
at Mipmap.main(Mipmap.java:24)



 Comments   
Comment by brainbr [ 09/Dec/08 ]

Created an attachment (id=134)
Test case

Comment by brainbr [ 09/Dec/08 ]

Created an attachment (id=135)
Test image

Comment by brainbr [ 13/Apr/09 ]

Created an attachment (id=138)
Here is my patch to fix this bug





[JOGL-371] Problem building JOGL source on Win64 Created: 01/Apr/09  Updated: 03/Apr/09

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: djclayworth Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: Other


Issuezilla Id: 371

 Description   

'm building the JOGL source tree on 64 bit Windows XP and I'm getting the
following message:

[cc] WindowsDynamicLinkerImpl_JNI.obj : fatal error LNK1112: module machine type
'X86' conflicts with target machine type 'x64'

I'm aware of what it means (trying to link 32 bit objects into a 64 bit DLL) but
I'm unclear on how to cure this, or even if it's a bug in the build scripts. I'm
using MSVC8.



 Comments   
Comment by kbr [ 03/Apr/09 ]

We build 64-bit JOGL for Windows on Windows XP 64 with Visual Studio 2005. I don't have the time to
look into what might be happening right now but recommend you build with ant -v and look at the
command line arguments and paths passed to the compiler.





[JOGL-370] Potential crash calling glXDestroyContext Created: 26/Mar/09  Updated: 26/Mar/09

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: djclayworth Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Other


Issuezilla Id: 370

 Description   

I have been debugging an issue which showed up on Ubuntu 8.04 and 8.10. My
application asks for a context, and JOGl creates an X11GLContext in response. An
attempt to make this context current then fails, as sometimes happens, and a
GLException is correctly thrown. My application then destroys the context. At
the point of destroying the context a core dump occurs, generating an hs_err file.

Closer inspection shows that in X11GLContext the variable 'mostRecentDisplay' is
not set during either the constructor, createContext() or makeCurrentImpl() (if
GLX.glXMakeCurrent() returns false). However in destroyImpl() there is a call
GLX.glXDestroyContext(mostRecentDisplay, context). The value of
mostRecentDisplay is zero.

I believe that this is the cause of the problem. The documentation I have found
for glXDestroyContext() does not indicate that null is a valid input. If I
modify a local copy of JOGl to set mostRecentDisplay to drawable.getDisplay()
then the crash does not occur.

I haven't tested this code change very much; it just seems to work in our case.
I hope this is helpful.






[JOGL-359] Problem when hardware rendering fails Created: 09/Jul/08  Updated: 03/Mar/09

Status: Reopened
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: djclayworth Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 359

 Description   

I have an application where I am drawing a number of GLJPanels in a component
(more than fifty). After drawing a few I get a GLException with the message:

pbuffer creation error: wglCreatePbufferARB() failed: tried 9 pixel formats,
last error was: (Unknown error code 0)

This is probably due to running out of resources (video memory?) and what I
expect. However what happens after that is unexpected. I start to get NPEs
whenever I draw any GLJPanel.

The GLException is thrown in GLDrawableFactory.createGLPbuffer() and caught in
GLJPanel.initialize(). GLJPanel.initialize() sets the flag
'hardwareAccelerationDisabled' true (meaning that software rendering will be
used from now on) and initializes the variables 'offscreenDrawable' and
'offscreenContext', which are needed for software rendering.

The trouble is that 'hardwareAccelerationDisabled' is static while
'offscreenDrawable' and 'offscreenContext' are not. This means that other
instances of GLJPanel are forced to do software rendering but without the
variables being initialised. This results in null pointers.

I am running on Windows XP with a Radeon X550 card. I'm using JOGL 1.1.1 with
JRE 5.0.



 Comments   
Comment by kbr [ 11/Jul/08 ]

I'm sorry, but the GLJPanel isn't intended to be used in this extreme fashion. I think you are going to
need to manually manage your off-screen rendering. Because you have the GLJPanel source code
available, you could create your own JPanel subclass which does similar operations to the GLJPanel to
interoperate with Java 2D, but which uses a common off-screen pbuffer for all of the components'
rendering, or something similar.

A restructuring of the GLJPanel's code is in progress which might make it easier to install better error
checking, but this would need to be left in the hands of the community as our development priorities
are elsewhere. Please watch the JOGL forum for updates.

Because this is an extreme use case, closing this bug as "won't fix".

Comment by djclayworth [ 03/Mar/09 ]

While I understand that this is an extreme case, I'm not asking that fifty
simultaneous GLJPanels are supported. In fact you don't need that many GLJPanels
to reproduce this; two GLJPanels is sufficient as long as
hardwareAccelerationDisabled is set true.

What I am asking is that when GLJPanel switches to hardwareAccelerationDisabled
it does so in a way that doesn't leave null pointers hanging - or alternatively
that the null pointers are checked for by each instance of GLJPanel when they
find hardwareAccelerationDisabled true.

TO REPRODUCE: Create two GLJPanels; perform some operation on one that causes
hardwareAccelerationDisabled to be set true internally; draw both GLJPanels.

EXPECTED: Both GLJPanels are drawn, either with or without hardware acceleration.

ACTUAL: Null pointer thrown.





[JOGL-369] Bug in GL_NV_framebuffer_coverage_multisample Created: 24/Feb/09  Updated: 24/Feb/09

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: triipaxx Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 369

 Description   

Hello,
i'm currently facing a problem with the extension
GL_NV_framebuffer_coverage_multisample. Some necessary values are set to wrong
value in the GL-Class.

The GL_MAX_MULTISAMPLE_COVERAGE_MODES_NV is set to 0x8E12 but is has to be set
to 0x8E11
and the GL_MULTISAMPLE_COVERAGE_MODES_NV is set to 0x8E13 but is has to be set
to 0x8E12
when i set these to variables to the correct values all is going well.....

for more informations check the specification of
NV_framebuffer_multisample_coverage...
i dunno if this is a known issue but i hope it's getting fixed in an upcomming
version of jogl

greetings
Jan






[JOGL-368] VM-Crash when using TextRenderer in DisplayList on ATI GPU Created: 02/Feb/09  Updated: 03/Feb/09  Resolved: 03/Feb/09

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Blocker
Reporter: miq Assignee: jogl-issues
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Attachments: Java Source File TextRendererDisplayListDemo.java    
Issuezilla Id: 368

 Description   

I experience a VM crash on a computer with a Radeon HD 3650 AGB when I use the
JOGL-TextRenderer in a DisplayList. Rendering text outside the list works as
expected. The same program works on a bunch of other computers with NVidia and
Intel GPUs.

Here is the vm-dump:
#

  1. An unexpected error has been detected by Java Runtime Environment:
    #
  2. EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x691b9c15, pid=2644, tid=2724
    #
  3. Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode, sharing windows-x86)
  4. Problematic frame:
  5. C [atioglxx.dll+0x199c15]
    #
  6. An error report file with more information is saved as:
  7. D:\workspace-miq(RAMSES) Ramses Module 3D Spektrum\hs_err_pid2644.log
    #
  8. If you would like to submit a bug report, please visit:
  9. http://java.sun.com/webapps/bugreport/crash.jsp
  10. The crash happened outside the Java Virtual Machine in native code.
  11. See problematic frame for where to report the bug.
    #


 Comments   
Comment by miq [ 02/Feb/09 ]

Created an attachment (id=137)
Sample program that crashes on the ATI GPU

Comment by kbr [ 02/Feb/09 ]

The TextRenderer really isn't designed for use in display lists – it may require flushing primitives to the
graphics card in the middle of the rendering of a large amount of text – but regardless the OpenGL
implementation shouldn't crash, but should signal an OpenGL error. You should report this crash to ATI
and provide them your test case. There is nothing to be done on the JOGL side to correct this. Closing as
"will not fix".

Comment by miq [ 03/Feb/09 ]

Ok, thanks for your fast and thorough reply. I will change the code accordingly.

Maybe it should be noted in the API documentation, that using the TextRenderer
in display lists may cause problems or is not recommended.

I will report the problem to ATI nevertheless.





[JOGL-367] File created by Screenshot might be flipped vertically Created: 28/Jan/09  Updated: 28/Jan/09

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: gibe Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 367

 Description   

When taking a screen shot using the Screenshot class, the exported image might
be flipped vertically.
Actually, it happens on Windows with GLJPanel and when pbuffers are disabled.

The problem comes from the vertical flip of the image by the Screenshot class.
Unlike the display method of the GLJPanel, the Screenshot class always performs
the flip. In the GLJPanel, before displaying the image, a check is done to know
whether the image should be flipped or not. This check obviously lacks in the
Screenshot class.



 Comments   
Comment by gibe [ 28/Jan/09 ]

Here is a workaround for the bug:
------------------------
// might unecessary flip the image
BufferedImage img = Screenshot.readToBufferedImage(getWidth(), getHeight());

// check if it was the case
boolean needFlip;
try

{ // raises an exception if hardware acceleration is on needFlip = !((GLContextImpl)GLContext.getCurrent()).offscreenImageNeedsVerticalFlip(); }

catch (GLException e)

{ // hardware acceleration is on needFlip = false; }

if (needFlip)

{ // flip it back ImageUtil.flipImageVertically(img); }

----------------

If you were using Screenshot.writeToFile, use the code above and
ImageIO.write(...) instead.





[JOGL-366] Replace pbuffer usage with FBO Created: 06/Jan/09  Updated: 09/Jan/09

Status: Reopened
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Trivial
Reporter: sylvestre12 Assignee: jogl-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501799


Issuezilla Id: 366

 Description   

Reported against the Debian package:

Playing with the JOGL demos, I found a bug in some demos provided by
the JOGL team available here:
https://jogl-demos.dev.java.net/

When I try the demos:

  • Hardware Shadow Mapping
  • JRefract

The command used is:
$ java -Djava.library.path=/usr/lib/jni/ -cp
/usr/share/java/jogl.jar:/usr/share/java/gluegen-rt.jar:.
demos.jrefract.JRefract

It seems that it is related to the pbuffer use.
I noticed that it worked perfectly with Nvidia proprietary drivers but
not at all with Intel drivers (some ATI drivers are working... recent
versions).



 Comments   
Comment by kbr [ 06/Jan/09 ]

There is nothing we can do about this in JOGL. This issue needs to be filed with the group or vendor
producing the graphics driver.

Comment by sylvestre12 [ 07/Jan/09 ]

Sorry for the confusion. I reported a bug since a developer of graphic drivers says:
"pbuffers are not supported in any existing release of our driver (or any
open-source driver, that I know of).

We're including EXT_framebuffer_object support in this quarterly release, and
if JOGL chose to replace pbuffer usage with the newer (better) extension, it
would work on our driver."

It is why I believed that it is a JOGL issue.

Reference: https://bugs.freedesktop.org/show_bug.cgi?id=17603#c1

Comment by kbr [ 07/Jan/09 ]

OK, I see. I'll reopen this bug.

There are a couple of things that would need to change. One would be to change the demos to use FBOs
instead of GLPbuffers explicitly. The other would be to write an FBO backend for the GLJPanel. This will be
easier in the forthcoming JOGL 2 where the GLJPanel has been refactored. You can see the source code for
this version under the JOGL_2_SANDBOX branch in the gluegen, jogl and jogl-demos workspaces.

The community will probably need to contribute these fixes.

Comment by sylvestre12 [ 09/Jan/09 ]

Answer received by a contributor - Jean-Baptiste Silvy (he has not the
permissions to reply to this message):

Concerning the backend for the GLJPanel, I think that we should keep the pbuffer
one.
Although FBOs are faster and more convenient than pBuffers, they are a pretty
recent OpenGL extension and may not be available on some old graphic cards.

Comment by kbr [ 09/Jan/09 ]

An FBO backend can be added to the GLJPanel without removing the GLPbuffer backend. The refactored
GLJPanel in the JOGL_2_SANDBOX branch makes this easier. Backends can be replaced on the fly.





[JOGL-363] Upgrade SGI FreeB license headers Created: 23/Sep/08  Updated: 09/Jan/09

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Attachments: Text File jogl-license.patch    
Issuezilla Id: 363

 Description   

SGI just donated all of the code previously covered under their FreeB license to
the open-source community by revising the FreeB license to mirror the X11
license. We should upgrade all of the FreeB headers in the JOGL workspace for
JOGL 2.0.



 Comments   
Comment by caniszczyk [ 09/Jan/09 ]

Created an attachment (id=136)
JOGL License Patch





[JOGL-364] TextRenderer broken under Max OSX 10.5.5 Created: 26/Sep/08  Updated: 30/Sep/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: qwerty999 Assignee: jogl-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 364

 Description   

OS X release 10.5.5 causes all text rendered via the TextRenderer to become garbled. This has been
reported on both the JOGL forums and the Apple Developer forums with no response. It is unclear what is
causing this problem and whether or not it is confined to particular video cards, etc.



 Comments   
Comment by qwerty999 [ 26/Sep/08 ]

Btw, neither of the following have helped (which were suggestions from other bugs with TextRenderer
issues):

setUseVertexArrays(false);
recompiling and forcing usingVBOs = false;

Bug occurs with every font I've tried at every size. It occurs on every program I've tried that uses
TextRenderer.

Comment by kbr [ 26/Sep/08 ]

Sorry, I haven't been keeping up on the forums. Thanks for the report.

This is a hardware-specific bug; it doesn't happen on 10.5.5 with Intel Integrated Graphics hardware,
but does with NVidia hardware.

It appears that glTexSubImag2D calls are broken pretty badly – as far as we can tell they are using the
previous call's data for subsequent calls. The workaround is to change the markDirty() calls in the
TextRenderer to zap the entire backing store instead of just the rectangle corresponding to the current
glyph.

Needless to say, we do not want to put such a hack workaround into JOGL. We are working with Apple to
get confirmation, diagnosis and resolution of this bug.

Comment by qwerty999 [ 30/Sep/08 ]

A thread was started on the apple developer forums as well by other frustrated 10.5.5 users:

http://discussions.apple.com/thread.jspa?messageID=8147129#8147129

-sj





[JOGL-356] TextRenderer causes a GLException on pre-OpenGL 1.5 version Created: 01/Jun/08  Updated: 12/Sep/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: javalution Assignee: jogl-issues
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File HelloWorldDemo.java     Text File hs_err_pid10635.txt     Java Source File TextRenderer.java     Java Source File TextRenderer.java     Java Source File TextRenderer.java     Java Source File TextRenderer.java     Java Source File TextRenderer.java     Java Source File TextRenderer.java    
Issuezilla Id: 356

 Description   

On JOGL 1.1.1 release candidate 5, the JVM crashes completely and produces a log
file. The other release candidates (rc6, rc7 and rc8) and the stable current
version produces the following trace:

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: array
vertex_buffer_object must be disabled to call this method
at com.sun.opengl.impl.GLImpl.checkBufferObject(GLImpl.java:30667)
at com.sun.opengl.impl.GLImpl.checkArrayVBODisabled(GLImpl.java:30715)
at com.sun.opengl.impl.GLImpl.glVertexPointer(GLImpl.java:27936)
at
com.sun.opengl.util.j2d.TextRenderer$Pipelined_QuadRenderer.drawVertexArrays(TextRenderer.java:1771)
at
com.sun.opengl.util.j2d.TextRenderer$Pipelined_QuadRenderer.draw(TextRenderer.java:1745)
at
com.sun.opengl.util.j2d.TextRenderer$Pipelined_QuadRenderer.access$000(TextRenderer.java:1687)
at
com.sun.opengl.util.j2d.TextRenderer.flushGlyphPipeline(TextRenderer.java:809)
at com.sun.opengl.util.j2d.TextRenderer.endRendering(TextRenderer.java:705)
at com.sun.opengl.util.j2d.TextRenderer.endRendering(TextRenderer.java:541)
at HelloWorldDemo.display(HelloWorldDemo.java:82)
at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)
at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:435)
at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)
at
javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:412)
at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)
at javax.media.opengl.GLCanvas.paint(GLCanvas.java:277)
at sun.awt.RepaintArea.paintComponent(RepaintArea.java:248)
at sun.awt.X11.XRepaintArea.paintComponent(XRepaintArea.java:56)
at sun.awt.RepaintArea.paint(RepaintArea.java:224)
at sun.awt.X11.XComponentPeer.handleEvent(XComponentPeer.java:683)
at java.awt.Component.dispatchEventImpl(Component.java:4489)
at java.awt.Component.dispatchEvent(Component.java:4243)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
Exception in thread "Thread-1" javax.media.opengl.GLException:
javax.media.opengl.GLException: array vertex_buffer_object must be disabled to
call this method
at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:271)
at
javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:410)
at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)
at com.sun.opengl.util.Animator.display(Animator.java:144)
at com.sun.opengl.util.Animator$MainLoop.run(Animator.java:181)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.media.opengl.GLException: array vertex_buffer_object must be
disabled to call this method
at com.sun.opengl.impl.GLImpl.checkBufferObject(GLImpl.java:30667)
at com.sun.opengl.impl.GLImpl.checkArrayVBODisabled(GLImpl.java:30715)
at com.sun.opengl.impl.GLImpl.glVertexPointer(GLImpl.java:27936)
at
com.sun.opengl.util.j2d.TextRenderer$Pipelined_QuadRenderer.drawVertexArrays(TextRenderer.java:1771)
at
com.sun.opengl.util.j2d.TextRenderer$Pipelined_QuadRenderer.draw(TextRenderer.java:1745)
at
com.sun.opengl.util.j2d.TextRenderer$Pipelined_QuadRenderer.access$000(TextRenderer.java:1687)
at
com.sun.opengl.util.j2d.TextRenderer.flushGlyphPipeline(TextRenderer.java:809)
at com.sun.opengl.util.j2d.TextRenderer.endRendering(TextRenderer.java:705)
at com.sun.opengl.util.j2d.TextRenderer.endRendering(TextRenderer.java:541)
at HelloWorldDemo.display(HelloWorldDemo.java:82)
at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)
at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:435)
at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)
at
javax.media.opengl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:452)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

The problem is reproducible only with graphics cards that are not at least
compatible with OpenGL 1.5. When I use both VBOs and a TextRenderer, I get the
exception trace above with the following source code:

import java.awt.*;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import java.nio.FloatBuffer;

import com.sun.opengl.util.Animator;
import com.sun.opengl.util.BufferUtil;
import com.sun.opengl.util.j2d.TextRenderer;
import javax.media.opengl.GL;
import javax.media.opengl.GLCanvas;
import javax.media.opengl.GLCapabilities;
import javax.media.opengl.GLAutoDrawable;
import javax.media.opengl.GLEventListener;

public class HelloWorldDemo extends Frame implements GLEventListener{

private static final long serialVersionUID = 1L;
private TextRenderer textRenderer;
private int[] id=new int[1];
private FloatBuffer buffer=BufferUtil.newFloatBuffer(0);

public HelloWorldDemo(){
super("JOGL 1.1.1");
setLayout(new BorderLayout());
setSize(400, 400);
setLocation(40, 40);
setVisible(true);
GLCapabilities caps = new GLCapabilities();
caps.setDoubleBuffered(true);
caps.setHardwareAccelerated(true);
GLCanvas canvas = new GLCanvas(caps);
canvas.addGLEventListener(this);
add(canvas, BorderLayout.CENTER);
Animator anim = new Animator(canvas);
anim.start();
addWindowListener(new WindowAdapter(){
public void windowClosing(WindowEvent e)

{ System.exit(0); }

});
buffer.put(new float[]{});
buffer.position(0);
}

public void init(GLAutoDrawable drawable)

{ GL gl = drawable.getGL(); gl.glClearColor(0, 0, 0, 0); gl.glMatrixMode(GL.GL_PROJECTION); gl.glLoadIdentity(); gl.glOrtho(0, 1, 0, 1, -1, 1); textRenderer=new TextRenderer(new Font("SansSerif",Font.PLAIN,12)); gl.glGenBuffers(1,id,0); gl.glBindBuffer(GL.GL_ARRAY_BUFFER,id[0]); gl.glBufferData(GL.GL_ARRAY_BUFFER,BufferUtil.SIZEOF_FLOAT*buffer.capacity(),buffer,GL.GL_STATIC_DRAW_ARB); this.buffer.position(0); }

public void reshape(GLAutoDrawable drawable,
int x,
int y,
int width,
int height){
}

public void displayChanged(GLAutoDrawable drawable,
boolean modeChanged,
boolean deviceChanged){
}

public void display(GLAutoDrawable drawable)

{ GL gl = drawable.getGL(); gl.glClear(GL.GL_COLOR_BUFFER_BIT); gl.glEnableClientState(GL.GL_VERTEX_ARRAY); gl.glEnableClientState(GL.GL_TEXTURE_COORD_ARRAY); gl.glBindBuffer(GL.GL_ARRAY_BUFFER,id[0]); gl.glDrawArrays(GL.GL_QUADS,0,0); gl.glDisableClientState(GL.GL_TEXTURE_COORD_ARRAY); gl.glDisableClientState(GL.GL_VERTEX_ARRAY); textRenderer.beginRendering(100,100); textRenderer.draw("JOGL 1.1.1",0,0); textRenderer.endRendering(); gl.glFlush(); }

public static void main(String[] args)

{ HelloWorldDemo demo = new HelloWorldDemo(); demo.setVisible(true); }

}



 Comments   
Comment by javalution [ 01/Jun/08 ]

Created an attachment (id=126)
Log file obtained when the JVM crashed with JOGL 1.1.1 release candidate 5

Comment by javalution [ 01/Jun/08 ]

Created an attachment (id=127)
source code to reproduce the bug easily

Comment by javalution [ 01/Jun/08 ]

I have found a workaround that works sometimes.

Explicitly unbind the last buffer you use by doing this:
gl.glBindBuffer(GL.GL_ARRAY_BUFFER,0);

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 (not yet tested as I don't succeed in building JOGL):

in com.sun.opengl.util.j2d.TextRenderer:
...
[color=red][b]private boolean bindBufferAvailable;[/b][/color]
...
public TextRenderer(Font font, boolean antialiased,
boolean useFractionalMetrics, RenderDelegate renderDelegate,
boolean mipmap)

{ [color=red][b]GL gl = GLU.getCurrentGL(); bindBufferAvailable = gl.isFunctionAvailable("glBindBufferARB") || gl.isFunctionAvailable("glBindBuffer");[/b][/color] ... }

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

{ [color=red][b]if(bindBufferAvailable) gl.glBindBuffer(GL.GL_ARRAY_BUFFER,0);//unbinds any already bound buffer[/b][/color] gl.glVertexPointer(3, GL.GL_FLOAT, 0, mVertCoords); }
Comment by javalution [ 01/Jun/08 ]

The workaround always works if it is called just before beginRendering() and
begin3DRendering().

Comment by javalution [ 02/Jun/08 ]

Created an attachment (id=128)
Cleanest bug fix (force the use of VBO on OpenGL 1.4 if GL_ARB_vertex_buffer_object is available)

Comment by javalution [ 02/Jun/08 ]

Created an attachment (id=129)
Cleanest bug fix version 2 (GL_ARB_vertex_buffer_object can be supported in OpenGL 1.3 on some graphics cards)

Comment by kbr [ 03/Jun/08 ]

This fix doesn't do what you think it does and frankly I don't see how it can
possibly change the behavior. With this fix the sequence of operations is as
follows:

  • The TextRenderer thinks it has VBOs available
  • It attempts to call glBindBuffer
  • This fails because OpenGL 1.5 is not available
  • It falls back to the vertex array implementation
  • It calls glVertexPointer with a Buffer as argument even though a VBO is
    already bound and should fail in the same way as before

If you want to add a code path for ARB_vertex_buffer_object you are going to
need to change the calls to glBindBuffer, etc. to instead call glBindBufferARB
in this case.

Comment by javalution [ 03/Jun/08 ]

I don't succeed in building JOGL, it doesn't help... When you call glBindBuffer
under OpenGL 1.3 through JOGL 1.1.1, it works like glBindBufferARB, my graphics
card is compatible with OpenGL 1.3 (ATI Radeon 9250 Pro) and using glBindBuffer
works, I tested this point, I replaced all calls of glBindBufferARB by
glBindBuffer and this didn't fail. The indirect rendering by Mesa supports only
OpenGL 1.2, therefore it doesn't come from this. With this fix, the sequence of
operations should be:

  • The TextRenderer thinks it has VBOs available
  • It attempts to call glBindBuffer
  • It works as glBindBuffer points on glBindBufferARB
    Did you test my fix with graphics cards compatible with OpenGL 1.4 or OpenGL 1.3
    only?
    Could you include my fix in the nightly build to allow me to test it or do you
    prefer me to try again to build JOGL with my fix before adding it into the
    nightly build?
Comment by javalution [ 03/Jun/08 ]

Created an attachment (id=130)
Cleanest bug fix version 3 following Kenneth Russell's suggestions

Comment by kbr [ 03/Jun/08 ]

You must test and validate your own fix before I will consider checking it in. I
do not have access to graphics cards supporting only OpenGL 1.3 / 1.4 any more.

Comment by javalution [ 03/Jun/08 ]

Created an attachment (id=131)
Cleanest bug fix version 4 (tested, works but has poor performance)

Comment by javalution [ 03/Jun/08 ]

The versions 2 and 3 of the bug fix crashes the JVM. The version 4 works but has
very poor performance. I don't find a competitive solution. Please investigate.
I don't understand why the JVM crashes on glDrawArrays after some seconds.

Comment by javalution [ 19/Aug/08 ]

Created an attachment (id=132)
Final cleanest fix, tested under OpenGL 1.3

Comment by javalution [ 19/Aug/08 ]

The latest bug fix works good. The impact on the performance is not really
noticeable if and only if you use VBOs whose element count is less than
GL_MAX_ELEMENTS_VERTICES.

I tried other approaches some weeks but the JVM crashed several times. This fix
is the only reliable and performant solution I have found. Please include it in
the nightly build as soon as possible.

Comment by javalution [ 19/Aug/08 ]

Created an attachment (id=133)
Fix handling the crash with Intel chips and working with OpenGL 1.4 too

Comment by javalution [ 19/Aug/08 ]

Please test the latest fix with an Intel on-board graphics and under OpenGL 1.4
as I don't have such things at home. I had forgotten some try/catch. Now, it
should be fine.

Comment by javalution [ 12/Sep/08 ]

Sorry. The fix doesn't work fine on some versions of Mesa, TUER crashes after 99
seconds, the JVM writes a log file. I have had to use the older implementation
to fix the bug. glBindBufferARB seems to be very unstable when used to unbind a
buffer.





[JOGL-362] calculated dimensions for MipMaps smaller than 16x16 Created: 06/Sep/08  Updated: 06/Sep/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Task Priority: Major
Reporter: dahie Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 362

 Description   

Hello everybody!

I've been working on some DirectDraw-Surface tools. For now, mostly simple
stuff like texture loading, preview and MipMap generating, resaving. I used the
DDSImage-class from JOGL as base for the File-Handling and using JSquish for
DXT-(De)Compression.

When I implemented automatic generated MipMaps I stumbled upon a possible bug
in the DDSImage class. I hope this is the right place to address this, the
bugtracker seemed kinda dead.

Here is my scenario:
I generate an array of ByteBuffers, which contain the pixel data. Each
ByteBuffer is then compressed using a DXTn-method. This data-array is then
given to the DDSImage class to create a new DDSImage-Object, which then can be
written to disc.

Code:
DDSImage.createFromData(pixelformat, width, height, mipmapBufferArray);

This gave me an IllegalArgumentException in the initFromData()-method saying,
that the remaining data size for the lowest mipmaps exceeded the expected size.
In fact the compressed buffer could never be smaller than 16kbyte (8kbyte DXT1).

I did some research and found, that DXT-compressors always use the usual 8x8
pixel block for compression, even if the actual texture is smaller. So the
resulting compressed block is always of this size.
This is even hinted at the official DDS-Specification at MSDN

So now what is the problem. The current implementation of the expected mipmap
data size:

Code:
// Now check the mipmaps against this size
int curSize = topmostMipmapSize;
int totalSize = 0;
for (int i = 0; i < mipmapData.length; i++) {
if (mipmapData[i].remaining() != curSize)

{ throw new IllegalArgumentException("Mipmap level " + i + " didn't match expected data size (expected " + curSize + ", got " + mipmapData[i].remaining() + ")"); }
curSize /= 4;
totalSize += mipmapData[i].remaining();
}

This always expects the datasize is 1/4 the size of the mipmap before. Works as
far as MipMaps are bigger or equal 8x8 pixels. In that case it throughs my
mentioned exception, as it expects the size to be smaller than it actually is.

I did some patch job to fix this.

Code:
// Now check the mipmaps against this size
int curSize = topmostMipmapSize;
int mipmapWidth = width;
int mipmapHeight = height;
int totalSize = 0;
for (int i = 0; i < mipmapData.length; i++) {
if (mipmapData[i].remaining() != curSize) { throw new IllegalArgumentException("Mipmap level " + i + " didn't match expected data size (expected " + curSize + ", got " + mipmapData[i].remaining() + ")"); }

/* Change

  • I got the problem, that MipMaps below the dimension of 8x8 blocks with
    DXTn
  • where assume smaller than they are created.
  • Assumed: smaller than 16byte where 16byte where used by the compression. */
    if(isCompressed) { // size calculation for compressed mipmaps if(mipmapWidth > 1) mipmapWidth /= 2; if(mipmapHeight > 1) mipmapHeight /= 2; curSize = computeCompressedBlockSize(mipmapWidth, mipmapHeight, 1, d3dFormat); }

    else

    { curSize /= 4; }

    /* changes end */
    totalSize += mipmapData[i].remaining();
    }

This patchjob is tested for saving DXT1-5 compressed files.
I bet it could be done a bit nicer, but it does the job.

I don't know if this can be classified as a bug, but I certainly think, the
original behavour was not desired and could be fixed in future versions.

So much from my part, hope this is patched in future releases.

best regards,
Dahie






[JOGL-361] Add information about TextRenderer transparency in Javadoc Created: 04/Sep/08  Updated: 04/Sep/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: gibe Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 361

 Description   

When depth test is enable, drawing of text must be performed after any other
object and sorted from back to front to ensure transparency correctness.

see: http://www.javagaming.org/index.php/topic,19115.0.html

This should be added in the TextRenderer Java doc.

Jean-Baptiste






[JOGL-360] cgGLSetParameterPointer's "pointer" is a buffer object Created: 03/Aug/08  Updated: 17/Aug/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kdubb Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 360

 Description   

cgGLSetParameterPointer takes a buffer object (to all using vbo's). In the Cg bindings this is only reflected
as a Buffer. It needs a variant that takes a long (like all the other methods that allow a vertex buffer
offset).



 Comments   
Comment by kbr [ 17/Aug/08 ]

Could you possibly try to modify jogl/make/cg-common.cfg and supply a patch? We
are swamped working on a branch of JOGL right now, and the fix may be a little
involved. See make/gl-common.cfg and the use of the BufferObjectKind directive.





[JOGL-358] Rendering on the browser.... Created: 25/Jun/08  Updated: 25/Jun/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: vinodpatel2006 Assignee: aaronanderson
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 358

 Description   

Hello,

This is not the issue but i am requesting an enhancement in the JOGL API.
The problem is that JOGL does not able to render on the browser window. I must
have to use applet to render the 3D objects. But what if i have to render on the
browser window. Rendering on the browser window means i have to use browser
window as the drawable. That is possible using the C++, i can make browser
window as drawable and send all rendering things on that. I can provide the
examples also that this is possible in C++.

I think that if that would be possible in the JOGL then it may be a great
feature and changes the impression of the JOGL.

I am waiting for you decision......

Thanks and Regards






[JOGL-357] JOGLInteroperability demo fails on openjdk Created: 04/Jun/08  Updated: 04/Jun/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Blocker
Reporter: boris_kolar Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 357

 Description   

Exception "Error making context current" is thrown when I launch
JOGLInteroperability demo, using openjdk on linux.

Steps to reproduce:

Using HP laptop with ATI Mobility Radeon X1600 running Ubuntu 8.04 desktop with
openjdk-6-jdk installed. The issue is not related to Netbeans or opengl plugin
(I tried running anything using GLJPanel and the same issue appears).

OPTIONAL: 1. Download Netbeans 6.1
OPTIONAL: 2. Install https://netbeans-opengl-pack.dev.java.net/
3. Run JOGLInteroperabilityDemo and select something from "Actions" menu

Exception will be thrown. Details:

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: Error
making context current
at
com.sun.opengl.impl.x11.X11GLContext.makeCurrentImpl(X11GLContext.java:141)
at
com.sun.opengl.impl.x11.X11OffscreenGLContext.makeCurrentImpl(X11OffscreenGLContext.java:74)
at com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:134)
at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:182)
at javax.media.opengl.GLJPanel.paintComponent(GLJPanel.java:661)
at demos.jgears.JGears.paintComponent(JGears.java:56)
at javax.swing.JComponent.paint(JComponent.java:1038)
at javax.swing.JComponent.paintChildren(JComponent.java:875)
at javax.swing.JComponent.paint(JComponent.java:1047)
at javax.swing.JComponent.paintChildren(JComponent.java:875)
at javax.swing.JComponent.paint(JComponent.java:1047)
at javax.swing.JComponent.paintChildren(JComponent.java:875)
at javax.swing.JComponent.paint(JComponent.java:1047)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:581)
at javax.swing.JComponent.paintChildren(JComponent.java:875)
at javax.swing.JComponent.paint(JComponent.java:1047)
at javax.swing.JComponent.paintChildren(JComponent.java:875)
at javax.swing.JComponent.paint(JComponent.java:1047)
at javax.swing.JComponent.paintChildren(JComponent.java:875)
at javax.swing.JComponent.paint(JComponent.java:1047)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:581)
at javax.swing.JComponent.paintChildren(JComponent.java:875)
at javax.swing.JComponent.paint(JComponent.java:1047)
at javax.swing.JComponent.paintChildren(JComponent.java:875)
at javax.swing.JComponent.paint(JComponent.java:1047)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:581)
at javax.swing.JComponent.paintChildren(JComponent.java:875)
at javax.swing.JComponent.paint(JComponent.java:1047)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5147)
at
javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:302)
at javax.swing.RepaintManager.paint(RepaintManager.java:1145)
at javax.swing.JComponent._paintImmediately(JComponent.java:5095)
at javax.swing.JComponent.paintImmediately(JComponent.java:4905)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:740)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:696)
at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:676)
at javax.swing.RepaintManager.access$700(RepaintManager.java:57)
at
javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1550)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:226)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:602)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)
java.lang.reflect.InvocationTargetException
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1000)
at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1348)
at com.sun.opengl.util.Animator.display(Animator.java:158)
at com.sun.opengl.util.FPSAnimator$1.run(FPSAnimator.java:95)
at java.util.TimerThread.mainLoop(Timer.java:534)
at java.util.TimerThread.run(Timer.java:484)
...






[JOGL-355] Need a way to get a list of GLCapabilities without a drawing surface. Created: 07/May/08  Updated: 07/May/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kenchapin Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 355

 Description   

I would like to be able to get a list of GLCapabilities objects that represents
all of the pixel formats or frame buffer configurations that are available in
the underlying OpenGL renderer and then know what kind of drawing surface a
particular GLCapabilities object is applicable for. There should be a mask of
drawable types added to the GLCapabilities class.

This is analogous to how Windows OpenGL works by either using
DescribePixelFormat() or the WGL_ARB_pixel_format extension querying routines.

This is also analogous to how GLX works in an X11 environment by using the
glXGetFBConfigs request.

Currently there is no way in Jogl to see all of the possible attribute
combinations that can be used with a Pbuffer. There is no way of guaranteeing
the successful creation of a Pbuffer with a GLCapabilities object filled with
desirable attributes. There may be no Pbuffer available with those exact
capabilities.

Unfortunately I don't know if it is possible to implement the same functionality
in OSX since I have no experience on that platform.






[JOGL-350] build: Use system antlr automatically if jpackage-compatible system Created: 29/Mar/08  Updated: 19/Apr/08  Resolved: 19/Apr/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Task Priority: Major
Reporter: colinwalters Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File jogl-jpackage-build.patch    
Issuezilla Id: 350

 Description   

Hi, the jpackage.org (http://jpackage.org/) project defines a means by which
Java libraries can install into the base operating system; in a nutshell, jar
files are all placed in /usr/share/java.

The attached patch allows jogl's build system to automatically detect this, and
work out of the box on jpackage.org-compatible systems. This is an intermediate
step until JSR277 is complete.



 Comments   
Comment by colinwalters [ 29/Mar/08 ]

Created an attachment (id=121)
look up antlr in /usr/share/java

Comment by kbr [ 19/Apr/08 ]

Added available check of /usr/share/java/antlr.jar. Not fully tested.





[JOGL-351] build: use X.org layout Created: 29/Mar/08  Updated: 16/Apr/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: colinwalters Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File jogl-xorg.patch    
Issuezilla Id: 351

 Description   

X.org no longer installs into the legacy /usr/X11R6 directory since Fedora
6/RHEL 5, and the same is true of Debian-derived systems.



 Comments   
Comment by colinwalters [ 29/Mar/08 ]

Created an attachment (id=122)
use X.org library locations on Linux

Comment by kbr [ 16/Apr/08 ]

I believe that this change will break our nightly builds which are deliberately
performed on an older Ubuntu distribution. If you can provide an updated patch
that will guarantee that it will work with both the old or the new layout I'll
be glad to incorporate it.





[JOGL-354] Inclusion of a GLCanvas in a JFrame causes exception Created: 15/Apr/08  Updated: 16/Apr/08  Resolved: 16/Apr/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: esalbert Assignee: jogl-issues
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Attachments: Java Source File SimpleTest.java    
Issuezilla Id: 354

 Description   

When trying to compile a simple test program (just draws a triangle),

<pre>
package test;

import java.awt.BorderLayout;
import javax.media.opengl.*;
import javax.swing.*;

public class SimpleTest implements GLEventListener
{
public SimpleTest()

{ super(); }

public void init(GLAutoDrawable drw)

{ drw.setGL(new DebugGL(drw.getGL())); GL gl = drw.getGL(); gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT); gl.glLoadIdentity(); }

// init

public void display(GLAutoDrawable drw)

{ GL gl = drw.getGL(); gl.glColor3f(1.0F, 0.4F, 0.0F); gl.glBegin(GL.GL_TRIANGLES); gl.glVertex3f(0.0F, 0.0F, 0.0F); gl.glVertex3f(1.0F, 0.0F, 0.0F); gl.glVertex3f(1.0F, 1.0F, 0.0F); gl.glEnd(); }

// display

public void reshape(GLAutoDrawable drw, int x, int y, int wid, int hite)
{
} // reshape

public void displayChanged(GLAutoDrawable drw, boolean modeCh, boolean devCh)
{
} // displayChanged

public static void main(String[] argv)
{
GLCapabilities glCaps = new GLCapabilities();

// This line fails with the current (1.1.1.1-rc8 - February 22) build,
// but works if GLCanvas is changed to GLJPanel. With the 1.1.0
// release build, it works either way. When it fails, the JFrame, when
// first made visible, crashes with an IllegalArgumentException deep
// inside the GL class heirarchy.
GLCanvas canv = new GLCanvas(glCaps);

final JFrame fram = new JFrame("TestFrame");
fram.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
fram.setSize(640, 480);
fram.getContentPane().add(canv, BorderLayout.CENTER);
canv.addGLEventListener(new SimpleTest());
SwingUtilities.invokeLater(new Runnable()
{
public void run()

{ fram.setVisible(true); }

// run
});
} // main
} // SimpleTest
</pre>

I get the following exception if I use a GLCanvas:

<pre>
Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException:
java.lang.IllegalArgumentException:

argument type mismatch
at
com.sun.opengl.impl.JAWT_DrawingSurfaceInfo.newPlatformInfo(JAWT_DrawingSurfaceInfo.java:86)
at
com.sun.opengl.impl.JAWT_DrawingSurfaceInfo.platformInfo(JAWT_DrawingSurfaceInfo.java:52)
at

com.sun.opengl.impl.windows.WindowsOnscreenGLDrawable.lockSurface(WindowsOnscreenGLDrawable.java:189)
at

com.sun.opengl.impl.windows.WindowsOnscreenGLContext.makeCurrentImpl(WindowsOnscreenGLContext.java:57)
at com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:134)
at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:182)
at
javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:412)
at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)
at javax.media.opengl.GLCanvas.paint(GLCanvas.java:277)
at sun.awt.RepaintArea.paintComponent(RepaintArea.java:248)
at sun.awt.RepaintArea.paint(RepaintArea.java:224)
at sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.java:301)
at java.awt.Component.dispatchEventImpl(Component.java:4486)
at java.awt.Component.dispatchEvent(Component.java:4240)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
Caused by: java.lang.IllegalArgumentException: argument type mismatch
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.opengl.impl.JAWT_DrawingSurfaceInfo.newPlatformInfo(JAWT_DrawingSurfaceInfo.java:83)
... 20 more
</pre>

If I change "GLCanvas" to "GLJPanel" on the indicated line, it runs correctly.
Using the 1.1.0 release versions of the libraries, it worked either way.

Please let me know if I need to provide any more information. The machine is a
Dell Precision PWS390 computer running Windows XP Professional with a Core 2 CPU
and 2 GB of RAM. I did set the "-Dsun.java2d.noddraw=true" flag.

Thank you for considering this matter.

Eric Salberta



 Comments   
Comment by esalbert [ 15/Apr/08 ]

Created an attachment (id=125)
The source file which shows the problem.

Comment by kbr [ 16/Apr/08 ]

Without having time to run this test I can tell you with 99.9% certainty that
you have a mismatched jogl.dll and jogl.jar. Please clean all such files off
your system and download a fresh copy of JOGL. Please reopen this bug if the
problem persists.





[JOGL-352] distortion using TextRenderer (sometimes) Created: 30/Mar/08  Updated: 13/Apr/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: yug Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Attachments: PNG File distortion.png     Java Source File TextDistortion.java    
Issuezilla Id: 352

 Description   

Steps to reproduce:
1) compile&run attached class bugs.TextDistortion
2) a black window containing the string "ARGH" should appear
3) press space (toggles redraw) until the G is distorted as shown in the
attached screenshot.
I rarely have to press space more than 10 times to see the effect

jogl-1.1.1-pre-20080329
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: RADEON 9800 PRO
OpenGL version string: 2.1.7412 Release



 Comments   
Comment by yug [ 30/Mar/08 ]

Created an attachment (id=123)
Test class

Comment by yug [ 30/Mar/08 ]

Created an attachment (id=124)
screenshot

Comment by kbr [ 30/Mar/08 ]

Unfortunately I can't reproduce this problem on my NVidia GeForce FX Go700
mobile hardware with the current graphics drivers.

It's going to be very difficult for us to fix this without being able to
reproduce it in house.

If you specify -Djogl.texture.notexrect on the command line when running your
test case, does it affect the behavior? This would indicate either a bug in the
TextRenderer in the case where the texture rectangle extensions are being used,
or a driver bug with the handling of said extensions.

Comment by yug [ 30/Mar/08 ]

Too bad you can't reproduce it
No, -Djogl.texture.notexrect does not affect this behavior.

Problem still exists in driver version
OpenGL version string: 2.1.7536 Release

Comment by yug [ 31/Mar/08 ]

I am unable to reproduce it on:
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 865G 20061017 x86/MMX/SSE2
OpenGL version string: 1.3 Mesa 7.0.2

I guess it is a ati driver issue then. I will try to report it at
http://ati.cchtml.com

Comment by yug [ 31/Mar/08 ]

http://ati.cchtml.com/show_bug.cgi?id=1089

Comment by kbr [ 12/Apr/08 ]

Have you tried calling setUseVertexArrays(false) on the TextRenderer? We ran
into problems with Mac OS X machines with ATI hardware and that worked around
the issue.

Comment by yug [ 13/Apr/08 ]

Indeed, no distortion with setUseVertexArrays(false) ! Thanks for the hint!

Do you have a clue yet where the cause of this bug is hidden?
jogl? driver? hardware?

Comment by yug [ 13/Apr/08 ]

Bug does not occur either if I don't call setUseVertexArrays(false), but set
usingVBOs=false

Comment by kbr [ 13/Apr/08 ]

I am pretty sure this is a bug in ATI's drivers. We have seen this problem with
ATI hardware on multiple operating systems but not with NVidia's hardware, again
on multiple operating systems.





[JOGL-353] Threading.invokeOnOpenGLThread() needs more precise documentation Created: 07/Apr/08  Updated: 07/Apr/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 353

 Description   

Threading.invokeOnOpenGLThread() needs to be more precisely documented, in particular that it waits for
the Runnable to complete before returning. This was mentioned on the JOGL forum:

http://www.javagaming.org/forums/index.php?topic=18442.0






[JOGL-336] Add Mac OS X 64-bit support Created: 30/Dec/07  Updated: 30/Mar/08  Resolved: 30/Mar/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh
URL: http://www.javagaming.org/forums/index.php?topic=17937.0


Issuezilla Id: 336

 Description   

Support for 64-bit Mac OS X platforms should be added. See the above URL for needed modifications to
the build system and GlueGen runtime classes.



 Comments   
Comment by kbr [ 15/Feb/08 ]

Support has been added to the JOGL and GlueGen workspaces. It is necessary to
specify "macosx64fat" in jogl.properties and gluegen.properties when building.
We need to get a new Mac capable of running 64-bit Leopard in order to start
building universal binaries with 64-bit x86 code.

Comment by kbr [ 30/Mar/08 ]

The current nightly builds of JOGL now have 64-bit Mac OS X support. Closing as
fixed.





[JOGL-329] Potential issues with bi-directional text Created: 29/Oct/07  Updated: 30/Mar/08  Resolved: 30/Mar/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Attachments: JPEG File WWJ_Annotations_20.jpg    
Issuezilla Id: 329

 Description   

Patrick Murris from the NASA World Wind Java project has indicated some
potential issues with bi-directional text and the TextRenderer:

"""
I keep throwing foreign text from Wikipedia into the text renderer, and i'm
still wondering exactly what the application should handle and what does the
text renderer takes care of.

I must admit i am not very familiar with the subject of ltr vs rtl text
direction and such... not mentioning top to bottom. Still, looking at some
arabic text - and looking hard to follow the glyphs... i can tell there are some
ltr-rtl fighting in there - see screenshot (and look at both the textbox on the
left and the main text display over the globe).

My current Locale is french... i'm using arial, and i didnt try to switch
locales for text rendering either.

I can fairly imagine the application would have to handle (or know) whether the
text direction should be ltr or rtl and decide the text left/right edge location
accordingly. Then the text renderer should draw from the given x,y in the proper
direction. Is that the way it is supposed to work ? If yes, then how does the
application knows the proper text direction for a given text string ?
"""

The attached screen shot is an example.

I am not sure there is an issue here. The Swing JTextArea requires a
ComponentOrientation to get its text to render in the correct direction. The
JOGL TextRenderer should handle, and appears to be handling, combined
right-to-left and left-to-right glyphs on the same line correctly.



 Comments   
Comment by kbr [ 29/Oct/07 ]

Created an attachment (id=109)
Screen shot showing difference between JTextArea and TextRenderer

Comment by kbr [ 30/Mar/08 ]

At this point I don't think there is a bug in the JOGL TextRenderer. Closing as
"invalid". Reopen this bug or file a new one if there is a concrete issue with a
test case.





[JOGL-314] JGears loops throwing GLException Created: 23/Aug/07  Updated: 30/Mar/08  Resolved: 30/Mar/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: mjw_java Assignee: jogl-issues
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: HP


Issuezilla Id: 314

 Description   

Running the JOGL demo demos.jgears.JGears results in an
endless loop of GLExceptions when java is started
with -Dsun.java2d.opengl=True.

The following repeats until java is exited:

exception in QueueFlusher:
javax.media.opengl.GLException: context creation error: couldn't find a suitable
frame buffer configuration
at
com.sun.opengl.impl.x11.X11ExternalGLDrawable$Context.create(X11ExternalGLDrawable.java:180)
at
com.sun.opengl.impl.x11.X11ExternalGLDrawable$Context.makeCurrentImpl(X11ExternalGLDrawable.java:123)
at com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:134)
at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:182)
at javax.media.opengl.GLJPanel$2.run(GLJPanel.java:650)
at sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run(OGLRenderQueue.java:203)

Platform is kubuntu linux 7.04, with
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: MOBILITY RADEON 9600
GL_VERSION: 2.0.6334 (8.34.8)

java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing)

jogl version nightly build 20070823.



 Comments   
Comment by kbr [ 24/Aug/07 ]

It's unlikely there is anything we can do about this problem in JOGL. It seems
that most vendors' OpenGL drivers have gotten much less stable with regard to
Frame Buffer Object implementation recently, and the Java 2D / OpenGL pipeline
barely works right now, let alone the Java 2D / JOGL bridge. The same code used
to work with older driver versions from various vendors including NVidia and
ATI. I would suggest you send a bug report to ATI. Nothing has changed in the
JOGL or Java SE code bases which would have introduced this instability, only
the vendors' graphics drivers.

Comment by kbr [ 30/Mar/08 ]

There hasn't been any action on this bug in a long while. Since I think this is
most likely an OpenGL driver problem I'm closing it as "invalid". Note that
there are some rewrites coming to the GLJPanel which should hopefully make it
work more reliably in conjunction with the Java 2D / OpenGL pipeline, and
changes to the Java 2D OpenGL pipeline itself to make it more reliable across a
wider range of graphics drivers.





[JOGL-313] gears demo crashes vm on window resize Created: 23/Aug/07  Updated: 30/Mar/08  Resolved: 30/Mar/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: mjw_java Assignee: jogl-issues
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: HP


Attachments: Text File hs_err_pid8687.log    
Issuezilla Id: 313

 Description   

Running the JOGL demo demos.gears.Gears causes the JVM to crash
when the window is resized and java was started with
-Dsun.java2d.opengl=True.

Platform is kubuntu linux 7.04, with
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: MOBILITY RADEON 9600
GL_VERSION: 2.0.6334 (8.34.8)

java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing)

jogl version nightly build 20070823.

JVM error:

#

  1. An unexpected error has been detected by Java Runtime Environment:
    #
  2. SIGSEGV (0xb) at pc=0x42ebcab0, pid=8687, tid=1207675792
    #
  3. Java VM: Java HotSpot(TM) Client VM (1.6.0_02-b05 mixed mode, sharing)
  4. Problematic frame:
  5. C [fglrx_dri.so+0x2cbab0]


 Comments   
Comment by mjw_java [ 23/Aug/07 ]

Created an attachment (id=104)
jvm crash report

Comment by kbr [ 24/Aug/07 ]

It's unlikely there is anything we can do about this problem in JOGL. It seems
that most vendors' OpenGL drivers have gotten much less stable with regard to
Frame Buffer Object implementation recently, and the Java 2D / OpenGL pipeline
barely works right now, let alone the Java 2D / JOGL bridge. The same code used
to work with older driver versions from various vendors including NVidia and
ATI. I would suggest you send a bug report to ATI. Nothing has changed in the
JOGL or Java SE code bases which would have introduced this instability, only
the vendors' graphics drivers.

Comment by kbr [ 30/Mar/08 ]

There hasn't been any action on this bug in a long while. Since I think this is
most likely an OpenGL driver problem I'm closing it as "invalid". Note that
there are some rewrites coming to the GLJPanel which should hopefully make it
work more reliably in conjunction with the Java 2D / OpenGL pipeline, and
changes to the Java 2D OpenGL pipeline itself to make it more reliable across a
wider range of graphics drivers.





[JOGL-312] Investigate dynamic downloading of JOGL Created: 06/Aug/07  Updated: 30/Mar/08  Resolved: 30/Mar/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://www.javagaming.org/forums/index.php?topic=16911.15


Issuezilla Id: 312

 Description   

The forum topic at http://www.javagaming.org/forums/index.php?topic=16911.15
shows a new technique for downloading JOGL dynamically for an applet. Should
look into it and consider any modifications it requires to JOGL in order to work.



 Comments   
Comment by kbr [ 30/Mar/08 ]

The path forward for dynamic downloading of JOGL is the new JNLP support in the
next-generation Java Plug-In, and the "lazy" attribute in the JNLP file format.
Please see http://jdk6.dev.java.net/plugin2/jnlp/ . The JNLPAppletLauncher is at
this point obsolete. Closing as "will not fix".





[JOGL-258] GtkLookAndFeel breaks GLSL shader Created: 15/Dec/06  Updated: 30/Mar/08  Resolved: 30/Mar/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: yug Assignee: jogl-issues
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 258

 Description   

Ok, this is completely insane. Please believe me anyway.
I have a simple program which draws two triangles using jogl.
Triangle A uses gl.glColor3d(0.9, 1.0, 0);
Triangle B uses a glsl shader.
Triangle B's fragment shader looks like this:
void main()
{
gl_FragColor=vec4(0.9,1.0,0.0,1.0);
}

When I run the program normally, both triangles are yellow.
If I run it with javaws, triangle B (the glsl triangle) is green!
In fact, every color value < 1.0 (in the fragment shader !!) is treated as 0.0
when I run the application with javaws.

I could track the problem back to
GtkLookAndFeel.initialize() which is called by javaws.
When I add new GtkLookAndFeel().initialize() as the first line of my
application, triangle B is also green when I run it directly with java (without
javaws). Reverting to MetalLookAndFeel does not help.

How the hell can GtkLookAndFeel break a glsl shader???

jdk 1.6.0-b105 linux i386
ati-drivers-8.32.5
jogl-1.1.0-pre-20061215-linux-i586



 Comments   
Comment by yug [ 15/Dec/06 ]

UNIXToolkit.checkGTK() seems to be sufficient to mess the colors up

Comment by kbr [ 23/Dec/06 ]

That's pretty weird. I haven't had time to test this yet but I strongly suspect
this is a bug in ATI's Linux graphics drivers. I don't think it can be anything
else since I doubt either the JDK or Gtk use OpenGL at all in the default case,
and even if they were, JOGL uses its own independent GLContext which should not
be able to interfere with any other one and vice versa.

I strongly recommend you put up a Java Web Startable test case and file a bug
with ATI. I may be able to get you into the ATI Linux beta program to file these
bugs more directly; please contact me via email if you'd like to try to join it.

Comment by kbr [ 30/Mar/08 ]

This bug has been sitting around for a while with no action. Since I can't
believe JOGL is responsible for this in any way I'm closing it as invalid.





[JOGL-279] GLJPanel.setAutoSwapBufferMode(false) throws NPE Created: 25/Feb/07  Updated: 30/Mar/08  Resolved: 30/Mar/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: dmgaskin Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 279

 Description   

package de.gaskin.jogl.bugs;

import javax.media.opengl.GLJPanel;

class DMGJOGLBug2 {
public static void main(String[] args)

{ GLJPanel panel = new GLJPanel(); panel.setAutoSwapBufferMode(false); }

}

Exception in thread "main" java.lang.NullPointerException
at javax.media.opengl.GLJPanel.setAutoSwapBufferMode(GLJPanel.java:758)
at de.gaskin.jogl.bugs.DMGJOGLBug2.main(DMGJOGLBug2.java:8)

Jogl VERSION

jogl-1.1.0-rc3-windows-i586



 Comments   
Comment by kbr [ 27/Feb/07 ]

This can be worked around by calling this method in the init() method of your
GLEventListener. Other methods on the GLJPanel have similar restrictions in the
current implementation. Downgrading from a P1.

Comment by kbr [ 30/Mar/08 ]

This issue turned up with NASA World Wind Java as well as with this
bug report.

The current situation is that GLJPanel.setAutoSwapBufferMode() and
GLJPanel.swapBuffers() have no effect due to how the Swing-compatible
GLJPanel works, and due to the fact that the backing OpenGL drawables
for the GLJPanel are always single-buffered.

Therefore there is no adverse effect to current applications to simply
making setAutoSwapBufferMode and swapBuffers no-ops, and returning
"true" from getAutoSwapBufferMode (although the latter is a change in
behavior, it reflects the current reality).





[JOGL-349] Enable multisampling on GLJPanel with Java2D pipeline enabled Created: 18/Mar/08  Updated: 18/Mar/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: chrisnf Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 349

 Description   

When -Dsun.jogl.opengl=true is set at runtime, these lines have no effect on the
rendering quality of a GLJPanel:

GLCapabilities capabilities = new GLCapabilities();
capabilities.setSampleBuffers(true);
capabilities.setNumSamples(8);
(create GLJPanel with these capabilities)
...

gl.glEnable(GL.GL_MULTISAMPLE);

Polygon edges still appear jagged at certain rotations. When the pipeline is
off, or a GLCanvas is used, the rendering looks smooth, as it should.






[JOGL-347] Line Strips rendered in the incorrect position. Created: 10/Mar/08  Updated: 14/Mar/08  Resolved: 14/Mar/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: alang Assignee: jogl-issues
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: PC


Attachments: Java Source File LineAlignmentBug.java     JPEG File Vista-Output-Incorrect.JPG     JPEG File XP-Output-Correct.JPG    
Issuezilla Id: 347

 Description   

Under certain circumstances line strips are renderer in the incorrect position
if flat shading is turned on. The attached example application draws a
triangle, and a line strip is used to draw a border around the triangle. On our
Windows XP machine the triangle and line strip are rendered correctly. On our
Windows Vista machine the line strip is drawn in the incorrect position.

Details about the Windows Vista machine are listed below:

  • OS : Windows Vista Business (no service pack)
  • Graphics : NVIDIA Geforce3
  • Drivers : Microsoft Driver 6.0.6000.16386
  • JVM : java 1.4.2_16 and 1.6.0_04
  • JOGL : 1.1.1-rc4 and 1.1.1-rc7


 Comments   
Comment by alang [ 10/Mar/08 ]

Created an attachment (id=118)
Java source code demostrating the bug.

Comment by alang [ 10/Mar/08 ]

Created an attachment (id=119)
Image showing XP output [Correct]

Comment by alang [ 10/Mar/08 ]

Created an attachment (id=120)
Image showing Vista output [Incorrect]

Comment by kbr [ 10/Mar/08 ]

There is very little possibility that this is a bug in JOGL. I would strongly
recommend you report this problem to the vendor of your graphics card, and/or
try updating your drivers to the latest available.

Comment by alang [ 14/Mar/08 ]

Thanks for that. Can confirm the problem seems to be with the Microsoft Driver
6.0.6000.16386 on Windows Vista. Upgrading the drivers to the lastest Nividia
references drivers fixes the issue. Cheers Alan





[JOGL-348] Add a method to change font in TextRender Created: 12/Mar/08  Updated: 12/Mar/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: gibe Assignee: jogl-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 348

 Description   

The TextRenderer lacks a setFont option.

For now, it's needed to create a new TextRenderer for each font to use.
However, user should avoid to allocate to many textrenderers outside the init
method (Specially, it seems that there are some memory leaks when destroying
TextRenderer).

Jean-Baptiste






[JOGL-346] Unable to load Gluegen native libraries on 64bit Windows (msvcr80.dll) Created: 28/Feb/08  Updated: 28/Feb/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: krisher Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 346

 Description   

Gluegen native libraries fail to load due to a missing dependency. We examined
the dependencies of the gluegen-rt.dll and it seems that the missing library is
msvcr80.dll.

There are several versions of this library installed on the system (both 32bit
and 64bit), however none seem to work with the Win-64 version of JOGL (The 32bit
distribution works fine with a 32bit Java VM). We have installed every version
of the x64 MSVCR80.DLL redistributable package that we could find from Microsoft
with no luck.

We have experienced this problem on Windows XP (x64) and Windows 2003 (x64).

java.lang.UnsatisfiedLinkError: C:\Documents and
Settings\mcvaya\jogl-natives\gluegen-rt.dll: Can't find dependent libraries

at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1647)
at java.lang.Runtime.load0(Runtime.java:770)
at java.lang.System.load(System.java:1005)
at
mil.afrl.rrs.ifsb.util.jogl.JOGLDynLoader.loadLibrary(JOGLDynLoader.java:220)
at
mil.afrl.rrs.ifsb.util.jogl.JOGLDynLoader.access$000(JOGLDynLoader.java:26)
at mil.afrl.rrs.ifsb.util.jogl.JOGLDynLoader$1.run(JOGLDynLoader.java:138)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)






[JOGL-345] Improve handling of pbuffers with non-power-of-2 sizes Created: 23/Feb/08  Updated: 23/Feb/08

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: peastman Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh


Issuezilla Id: 345

 Description   

On Mac OS X, if you create a GLPbuffer and specify a width or height that is not
a power of 2, it rounds the size up to the next power of two. This is confusing
and inconsistent with other platforms. It can be improved in several ways:

1. When the hardware supports non-power-of-2 textures, it should give you a
pbuffer of the size you requested.

2. If the hardware does not support it, it should throw an exception rather than
silently giving you a pbuffer of a different size than you requested. This will
save a lot of confusion and bugs. Programmers will discover their mistake
immediately rather than having the program seem to work but produce incorrect
results.

3. The Javadocs should discuss the limitations on pbuffer sizes so people will
be aware of them.

For more details, see this discussion thread:

http://www.javagaming.org/forums/index.php?topic=18218.0






[JOGL-344] Serious TextRenderer problems involving large fonts & unicode characters Created: 15/Feb/08  Updated: 17/Feb/08  Resolved: 17/Feb/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: qwerty999 Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 344

 Description   

There are issues with the TextRenderer utility class which causes problems
involving large fonts and/or long strings of text.

issue 1) Artifacts appear which distort/obscure the text, and cause the text to
flip back and forth.

issue 2) Unicode characters cause the program the crash.

For a screenshot of issue one, check out this thread:
http://www.javagaming.org/forums/index.php?topic=18177.0
(note that this isn't a screen shot of the test code below, but it also exhibits
the strange behavior).

Here is some test code (modified from TextCube.java in the JOGL demos). There
are two cases (uncomment one or the other in the constructor). The first case
shows that unicode characters crash JOGL if large fonts are used. The second
case shows the weird artifacts that flip back and forth when using large fonts
(and no unicode characters).

import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Font;
import java.awt.Frame;
import java.awt.event.*;
import java.awt.geom.*;

import javax.media.opengl.*;
import javax.media.opengl.glu.*;
import com.sun.opengl.util.*;
import com.sun.opengl.util.j2d.*;

/** Test Code adapted from TextCube.java (in JOGL demos) */

public class WeirdFontTest implements GLEventListener
{
GLU glu = new GLU();
TextRenderer renderer;

float textScaleFactor;
String text;
Font font;
boolean useMipMaps;

public WeirdFontTest()

{ //test 1 - unicode hangs program with a large font & long string //font = new Font("default", Font.PLAIN, 200); //text = "\u201Cabcdefghijklmnopqrstuvwxyz\u201D"; //test 2 - weird artifacts appear with a large font & long string font = new Font("default", Font.PLAIN, 200); text = "abcdefghijklmnopqrstuvwxyz1234567890"; useMipMaps = true; //false }

public static void main(String[] args)
{
Frame frame = new Frame("WeirdFontTest");
frame.setLayout(new BorderLayout());

GLCanvas canvas = new GLCanvas();
final WeirdFontTest demo = new WeirdFontTest();

canvas.addGLEventListener(demo);
frame.add(canvas, BorderLayout.CENTER);

frame.setSize(512, 512);
final Animator animator = new Animator(canvas);
frame.addWindowListener(new WindowAdapter()
{
public void windowClosing(WindowEvent e)
{
new Thread(new Runnable()
{
public void run()

{ animator.stop(); System.exit(0); }

}).start();
}
});
frame.show();
animator.start();
}

public void init(GLAutoDrawable drawable)

{ GL gl = drawable.getGL(); gl.glEnable(GL.GL_DEPTH_TEST); renderer = new TextRenderer(font, useMipMaps); Rectangle2D bounds = renderer.getBounds(text); float w = (float) bounds.getWidth(); float h = (float) bounds.getHeight(); textScaleFactor = 2.0f / (w * 1.1f); gl.setSwapInterval(0); }

public void display(GLAutoDrawable drawable)

{ GL gl = drawable.getGL(); gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT); gl.glMatrixMode(GL.GL_MODELVIEW); gl.glLoadIdentity(); glu.gluLookAt(0, 0, 10, 0, 0, 0, 0, 1, 0); renderer.begin3DRendering(); Rectangle2D bounds = renderer.getBounds(text); float w = (float) bounds.getWidth(); float h = (float) bounds.getHeight(); renderer.draw3D(text, w / -2.0f * textScaleFactor, h / -2.0f * textScaleFactor, 3f, textScaleFactor); renderer.end3DRendering(); }

public void reshape(GLAutoDrawable drawable, int x, int y, int width, int height)

{ GL gl = drawable.getGL(); gl.glMatrixMode(GL.GL_PROJECTION); gl.glLoadIdentity(); glu.gluPerspective(15, (float) width / (float) height, 5, 15); }

public void displayChanged(GLAutoDrawable drawable, boolean modeChanged,
boolean deviceChanged)
{
}
}



 Comments   
Comment by qwerty999 [ 15/Feb/08 ]

(changed description slightly)

Comment by kbr [ 16/Feb/08 ]

Thanks for the test case. Fixing this is going to require a large reorganization
of the code in the TextRenderer. I will promote 1.1.1-rc7 with the current code
and fix this for 1.1.1-rc8.

Comment by kbr [ 17/Feb/08 ]

The glyph-based rendering algorithm for the TextRenderer was
performing rendering in two steps: glyph preparation and upload, and
rendering. This structure doesn't work in the context of the
RectanglePacker, which can reorganize the backing store during any
upload.

Restructured the glyph cache in the TextRenderer in terms of flyweight
Glyph objects which know how to upload and render themselves. During
any upload, the outstanding glyphs not yet rendered to the screen may
thereby be flushed. Improved the code path which falls back to the
string-by-string algorithm for complex Unicode characters so that
incoming strings can be segmented into multiple parts which are
rendered either using the glyph cache or the string-by-string
algorithm.

Also tinkered with the bounds of glyphs and strings on the backing
store to try to more definitively eliminate bleed-over between
adjacent characters on the backing store, and to ensure that all of
the pixels of glyphs are drawn. Some heuristics are unfortunately
involved but the new code appears to work well with both very large
and very small fonts.

Added a few more test cases for the TextRenderer based on the bug
report. Tested with the previous test cases as well.

This fix will be in tomorrow's nightly build as well as the forthcoming
JOGL 1.1.1-rc8.





[JOGL-342] demos/j2d/TextFlow (TextRenderer) demo gives fuzzy text Created: 08/Feb/08  Updated: 15/Feb/08  Resolved: 15/Feb/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: slp7 Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://www.javagaming.org/forums/index.php?topic=18154.0


Attachments: PNG File text-flow.png     PNG File text-flow4.png    
Issuezilla Id: 342

 Description   

I'm using demos/j2d/TextFlow and the resulting text is fuzzy. The text is white
on black but left side of each letter is not white but rather a light grey and
the right side is a dark gray. The vertical transitions are always sharp, black
to white then white to black.

My own code also gives fuzzy text but since I'm using a smaller font size the
problem is much more noticeable. How can I get the nice crisp text shown in the
image on http://www.javagaming.org/forums/index.php?topic=15634.30 ?

I'm using jogl-1.1.1-rc7 on a Linux machine with a Intel Q35 graphics card:
LD_LIBRARY_PATH=jogl-1.1.1-rc7-linux-i586/lib java -classpath
jogl-demos.jar:jogl-demos-util.jar:jogl-1.1.1-rc7-linux-i586/lib/jogl.jar:jogl-1.1.1-rc7-linux-i586/lib/gluegen-rt.jar
demos/j2d/TextFlow



 Comments   
Comment by slp7 [ 08/Feb/08 ]

Created an attachment (id=116)
a screen image of demos/j2d/TextFlow showing fuzzy text

Comment by slp7 [ 08/Feb/08 ]

Created an attachment (id=117)
a 4 times enlargement of part of the demos/j2d/TextFlow program

Comment by kbr [ 12/Feb/08 ]

Added link to forum post.

Need some way of controlling this property at run time.

Comment by kbr [ 12/Feb/08 ]
      • Issue 343 has been marked as a duplicate of this issue. ***
Comment by kbr [ 15/Feb/08 ]

Added setSmoothing / getSmoothing to TextRenderer API to offer control
over filtering mode of the TextureRenderer backing store.





[JOGL-339] Add system properties to turn off VAs/VBOs in TextRenderer Created: 23/Jan/08  Updated: 15/Feb/08  Resolved: 15/Feb/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://www.javagaming.org/forums/index.php?topic=18080.0


Attachments: Java Source File TextRenderer.java    
Issuezilla Id: 339

 Description   

User emzic suggests on http://www.javagaming.org/forums/index.php?topic=18080.0
that there should be a way of disabling the use of vertex arrays and vertex
buffer objects in the TextRenderer to work around driver bugs or performance
problems.



 Comments   
Comment by kbr [ 30/Jan/08 ]

Created an attachment (id=115)
Proposed new TextRenderer from emzic

Comment by kbr [ 15/Feb/08 ]

Incorporated patch from emzic, slightly modified, to add
set/getUseVertexArrays() as concession to graphics cards which do not
perform well with small vertex arrays.





[JOGL-337] Compile linux amd64 version without dependency to glibc 2.4 Created: 04/Jan/08  Updated: 15/Feb/08  Resolved: 15/Feb/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: tkoeck Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Issuezilla Id: 337

 Description   

The nightly build packages for linux amd64 have a dependency to glibc 2.4
(symbol __stack_chk_fail@@GLIBC_2.4). Since there are current distributions
which don't have glibc 2.4 yet (like Debian Etch) it would be nice if the
build would not have this dependency. The linux i386 package does not have
this dependency (it still had it in the 1.0 packages).



 Comments   
Comment by kbr [ 07/Jan/08 ]

We'll see what we can do. Currently we're running an Ubuntu distro on our 64-bit
Linux nightly build machine which is why we have the glibc 2.4 dependence.

Comment by kbr [ 15/Feb/08 ]

This has been fixed by downgrading our 64-bit Ubuntu machine. Please reopen this
bug or open a new one if you continue to see a problem.





[JOGL-338] JOGL Applet launched with JNLPAppletLauncher fails on OS X Created: 17/Jan/08  Updated: 15/Feb/08  Resolved: 15/Feb/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: johan3210 Assignee: jogl-issues
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh
URL: http://www.demicron.com/johan/test.html


Issuezilla Id: 338

 Description   

We are using JNLPAppletLauncher for launching JOGL Applets. It works fine in
Windows, but it doesn't work in Safari on Mac. We have tried on four different
OS X systems and it fails on all of them (Tiger, Leopard, latest Java
version...). We have also tried the first JOGL Example from the Applet Launcher
Project Home page:

<applet code="org.jdesktop.applet.util.JNLPAppletLauncher"
width=600
height=400
archive="
http://download.java.net/media/applet-launcher/applet-launcher.jar,

http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jar
,
http://download.java.net/media/gluegen/webstart/gluegen-rt.jar,

http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl-demos.jar">
<param name="codebase_lookup" value="false">
<param name="subapplet.classname
" value="demos.applets.GearsApplet">
<param name="subapplet.displayname" value="JOGL Gears Applet">
<param name="noddraw.check" value="true">

<param name="progressbar" value="true">
<param name="jnlpNumExtensions" value="1">
<param name="jnlpExtension1"
value="
http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp">
</applet>

It also fails, with the same error message. The error message generated is the
following:

Mac OS X Version 10.4.11 (Build 8S165)
2008-01-02 07:58:47 -0600
2008-01-02 07:58:47.638 loginwindow[177] FSResolveAliasWithMountFlags returned
err = -35
2008-01-02 07:58:50.662 SystemUIServer[208] lang is:en
(timer):Null value
2008-01-09 07:54:12.264 SoftwareUpdateCheck[1108] Checking for updates
JNLPAppletLauncher: static initializer
os.name = mac os x
nativePrefix = lib nativeSuffix = .jnilib
tmpRootDir = /tmp/jnlp-applet/jln58888
Applet.init
subapplet.classname = com.wirefusion.player.GLAppletPlayer
subapplet.displayname = Untitled_1
Applet.start
Exception in thread "AppletLauncher-Startup" java.lang.NoClassDefFoundError:
IllegalName: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
at java.lang.ClassLoader.preDefineClass (ClassLoader.java:476)
at java.lang.ClassLoader.defineClass(ClassLoader.java:614)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java :163)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:119)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:88)
at
javax.xml.parsers.FactoryFinder.findJarServiceProvider(FactoryFinder.java:278)
at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java :185)
at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:107)
at
org.jdesktop.applet.util.JNLPAppletLauncher$JNLPParser.<clinit>(JNLPAppletLauncher.java:2180)
at org.jdesktop.applet.util.JNLPAppletLauncher.parseJNLPExtensions
(JNLPAppletLauncher.java:2020)
at
org.jdesktop.applet.util.JNLPAppletLauncher.initResources(JNLPAppletLauncher.java:1329)
at
org.jdesktop.applet.util.JNLPAppletLauncher.initAndStartApplet(JNLPAppletLauncher.java
:1254)
at
org.jdesktop.applet.util.JNLPAppletLauncher.access$000(JNLPAppletLauncher.java:658)
at
org.jdesktop.applet.util.JNLPAppletLauncher$1.run(JNLPAppletLauncher.java:907)

This issue has also been reported on the Applet Launcher project home page, but
I'm not sure if the problem is caused by JOGL or by Applet Launcher.



 Comments   
Comment by kbr [ 15/Feb/08 ]

This was confirmed by the user as a misconfiguration of their web server where
it was not properly returning the 404 status code for missing content, which is
absolutely required for the current applet class loader to work. Closing as Invalid.





[JOGL-343] Need way to control smoothing property of TextRenderer Created: 12/Feb/08  Updated: 12/Feb/08  Resolved: 12/Feb/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://www.javagaming.org/forums/index.php?topic=18154.0


Issuezilla Id: 343

 Description   

Some graphics cards (in particular Intel graphics cards on Linux) are performing
sub-optimal filtering of the TextRenderer's output, resulting in fuzzy edges for
the text. Need a way to control this and to explicitly force the TextRenderer to
use GL_NEAREST rather than GL_LINEAR filtering.

See http://www.javagaming.org/forums/index.php?topic=18154.0 .



 Comments   
Comment by kbr [ 12/Feb/08 ]

Didn't notice this had already been filed as Issue 342.

      • This issue has been marked as a duplicate of 342 ***




[JOGL-341] JNI Global Reference in native code prevents clean applet termination Created: 02/Feb/08  Updated: 02/Feb/08  Resolved: 02/Feb/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 341

 Description   

The JNI global reference in JAWT_DrawingSurfaceInfo.c which is used to help
construct the Java-side mirror for the JAWT "platformInfo" struct is preventing
clean termination of JOGL applets. This global reference keeps the
platform-specific PlatformInfo class (such as
com.sun.opengl.impl.windows.JAWT_Win32DrawingSurfaceInfo) alive, and therefore
its class loader alive, preventing unloading of the native library.

This may also be the root cause of mysterious ClassCastExceptions seen with JOGL
applets on Mac OS X, although it is likely that either a bug in the Java
implementation or misunderstood semantics of the dynamic linker on that platform
is the reason that problem has only been seen there.



 Comments   
Comment by kbr [ 02/Feb/08 ]

Simplified the native code in JAWT_DrawingSurfaceInfo.c to only
fabricate the direct ByteBuffer wrapping the JAWT "platformInfo"
struct, moving the construction of the wrapping JAWT_PlatformInfo up
to Java.

Verified fix with reloading of JOGL applets via the new JNLP applet
launching support in the new Java Plug-In.





[JOGL-340] glClearColor with alpha set to 0 + glRTeadPixels = fail Created: 31/Jan/08  Updated: 01/Feb/08  Resolved: 01/Feb/08

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: personwholives Assignee: jogl-issues
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 340

 Description   

I have an app where I am trying to render an image to a pbuffer, then save that
image to file. I call gl.glClearColor(0, 0, 0, 0) to make a black, transparent
background. After this, I render a few shapes and try to read the rendered
image back with gl.glReadPixels(0, 0, w, h, GL.GL_RGBA, GL.GL_UNSIGNED_BYTE, b).
However, the read back result suffers from a complete lack of transparency.
Even those places which I would expect to be transparent because nothing was
drawn there. Every pixel in the populated data buffer has an alpha of 0xFF.
This does not seem like correct behavior.

My system is a newer workstation class machine with an nVidia Quadro FX graphics
card, running windows XP. Test done with JSR 231 1.1.0 on java 1.6 JDK, run
from within eclipse. If any of that info is helpful.



 Comments   
Comment by personwholives [ 01/Feb/08 ]

Ok, I'm stupid. Please ignore/close this issue. One of these days I'll check
everything before leaping to the "it must be broken" conclusion.

Comment by kbr [ 01/Feb/08 ]

Closed as per submitter's comments.





[JOGL-135] GLCanvas should interact better with lightweights Created: 31/Jan/05  Updated: 30/Nov/07  Resolved: 30/Nov/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File GearsWithButtons.java     Java Source File ResizeIssue.java     Java Source File Test.java    
Issuezilla Id: 135

 Description   

Several issues were raised roughly a year and a half ago, when JOGL was
introduced, indicating that GLCanvas should behave better when placed in the
midst of lightweight components; in particular, that it should respect
setMinimumSize, setPreferredSize, and setMaximumSize, as I understand that
lightweight widgets do. We should investigate this issue and provide such
support. See JOGL Issue 17 for an example which seems to misbehave when Swing
widgets surround a GLCanvas.



 Comments   
Comment by kbr [ 01/May/05 ]

Created an attachment (id=47)
Test case illustrating problem

Comment by kbr [ 01/May/05 ]

This has come up again on the JOGL forum on javagaming.org:
http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1114904448

This problem appears to have no good solution. The root cause is behavior of the
Canvas, and in particular its ComponentPeer. The implementation of
getPreferredSize() calls getMinimumSize() and getMinimumSize() turns around and
calls Component.getSize(). This effectively means that the Canvas will report
its preferred size as being as large as the component has ever been. For some
layout managers this doesn't seem to matter, but for others like the BoxLayout
it does. See the attached test case for an example. Replacing the GLCanvas with
an ordinary Canvas yields the same behavior.

One suggestion was to override getPreferredSize() so that if a preferred size
has not been set by the user, to default to (0, 0). This works fine for the
supplied test case but breaks all of the other demos because they use a
different LayoutManager. There appear to be a lot of interactions between
heavyweight vs. lightweight widgets and layout managers. One experiment which
was done was to override setSize() in GLCanvas to update the preferred size.
This works down to the size specified by the user; if the window is resized any
smeller the same problem appears. If reshape() (the base routine of setSize(),
setBounds(), etc.) is changed to do the same thing, the demo breaks in the same
way it originally did. Therefore this solution is fragile because it isn't clear
which of these methods are used internally by the AWT and for what purposes.

There are two possible workarounds, both application-specific. The best and most
portable appears to be to put the GLCanvas into a JPanel and set the JPanel's
preferred size to (0, 0). The JPanel will cause this constraint to be enforced
on its contained GLCanvas. The other workaround is to call setPreferredSize(new
Dimension(0, 0)) on a newly-created GLCanvas; this method is new in 1.5.

This bug is being marked as "wontfix" because the behavior is unchanged from the
underlying Canvas class and it looks like making any change is going to break
something else.

Comment by kbr [ 01/May/05 ]

Created an attachment (id=48)
Test case from JOGL forums including commented-out workaround

Comment by moorej [ 30/Nov/07 ]

Created an attachment (id=114)
Updated resize issue to include new workaround and make it work with the ratified jogl release





[JOGL-335] gluErrorString throws an exception with some GLU errors Created: 29/Nov/07  Updated: 29/Nov/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jbsilvy Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 335

 Description   

gluErrorString throws ArrayIndexOutOfBoundsException with error GLU_TESS_ERROR5
(value 100155).

Jean-Baptiste






[JOGL-334] White textures if disabling mipmap Created: 18/Nov/07  Updated: 26/Nov/07  Resolved: 26/Nov/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: asantiago Assignee: jogl-issues
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Attachments: PNG File 400x230-splash-nww.png     PNG File georss.png     JPEG File smipmap_false.jpg     JPEG File smipmap_true.jpg    
Issuezilla Id: 334

 Description   

The problem is here:

textureData = TextureIO.newTextureData(iconStream, true, null);

later the data is set to a texture object. If the mipmap option is set to
'false' then some images are rendered as white textures.
The images type is not relevant because, for example, some PNG image are
rendered right and some don't.
I attach this URL where I have put a couple of images:
http://theballoonproject.blogspot.com/2007/11/jogl-mipmap-problem.html

Thanks.



 Comments   
Comment by asantiago [ 18/Nov/07 ]

Created an attachment (id=110)
Mimmap set to false

Comment by asantiago [ 18/Nov/07 ]

Created an attachment (id=111)
Mipmap set to true

Comment by asantiago [ 18/Nov/07 ]

Created an attachment (id=112)
Problematic image

Comment by asantiago [ 18/Nov/07 ]

Created an attachment (id=113)
No problematic image

Comment by asantiago [ 18/Nov/07 ]

Sorry, the JOGL version is "1.1.1-pre-20070918-02:11:29."

Comment by kbr [ 18/Nov/07 ]

Need more information. Please attach the output of demos.misc.PrintExt from the
jogl-demos workspace. Please indicate whether demos.texture.TestTexture shows
the problem; note that you will need to recompile this demo so that it calls
TextureIO.newTexture(file, false) instead of TextureIO.newTexture(file, true).
Note that I can not reproduce this problem on my system, but it probably has
different non-power-of-two capabilities than yours.

Also please verify that the texture coordinates you are computing for the mapped
image are based on Texture.getImageTexCoords() or getSubImageTexCoords(), as
those are the only guaranteed ways to get the correct texture coordinates for
the loaded image, especially if non-power-of-two textures are in use (which they
are here).

Comment by asantiago [ 21/Nov/07 ]

Finally I have run the demos.texture.TestTexture and as you point it works fine.
I tested for JOGL rc7 and for the same version used by WorldWind, both works fine.

I report it as a problem in the WWJ project, I am not the only one with this
problem.
Thanks a lot.

Comment by kbr [ 26/Nov/07 ]

Closing as "works for me".





[JOGL-333] Make it possible to specify the name of native libraries Created: 17/Nov/07  Updated: 17/Nov/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: fabriziogiudici Assignee: jogl-issues
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 333

 Description   

There are some problems if people try to integrate JOGL with NetBeans RCP and want to run on more
than one Unix (e.g. Linux + Solaris) or Windows (e.g. 32 + 64bits) system. This is due to the fact that
NetBeans expects that all the native libraries for a given component are packed in the same directory -
hence the problem since all Unix systems share the name libjogl.so.

It's clearly not a JOGL problem but a NetBeans problem, but it won't be solved in a short time.
Evaluating a few workarounds to this, it seems to me that the thing that would make the programmer's
life easier would be a set of properties (e.g. jogl.nativelibrary.name.

{jogl,jogl_awt,jogl_cg}

or whatever)
that could be used to override the default names of the searched libraries. Not specifing them would
have the system behave as today; their presence would allow the programmer to rename the native
libraries (e.g. libjogl-linux-64.so), guess which the current operating system is and compose the
proper library name.

Leaving the o.s. detection and consequential the choice of the library name to the programmer should
make this RFE a low risk for JOGL developers.






[JOGL-332] TextRenderer depends on OpenGL 1.3 glClientActiveTexture Created: 14/Nov/07  Updated: 14/Nov/07  Resolved: 14/Nov/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://www.javagaming.org/forums/index.php?topic=17710.0


Issuezilla Id: 332

 Description   

The TextRenderer currently has a dependence on the glClientActiveTexture API
introduced in OpenGL 1.3. It turns out that this is a meaningless dependence and
that the code using it is actually incorrect as written. The solution is to
simply remove the call.



 Comments   
Comment by kbr [ 14/Nov/07 ]

Removed call to glClientActiveTexture, which was incorrect as written since the
texture object was being bound to the current texture unit and then the active
texture unit forced to GL_TEXTURE0 just before setting up the texture coordinate
pointer. Tested with text demos in jogl-demos workspace.





[JOGL-326] TextRenderer corruption with certain text Created: 22/Oct/07  Updated: 09/Nov/07  Resolved: 09/Nov/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC
URL: http://www.javagaming.org/forums/index.php?topic=15594.90


Attachments: Java Source File TextTest.java    
Issuezilla Id: 326

 Description   

The thread above and attached test case indicate a problem with the TextRenderer
where its output becomes corrupted after rendering certain text sequences
involving the ASCII letter '-' and some surrounding text.



 Comments   
Comment by kbr [ 22/Oct/07 ]

Created an attachment (id=108)
Test case

Comment by kbr [ 25/Oct/07 ]

Another piece of text which breaks courtesy of Patrick Murris from the NASA
World Wind Java project:

Font.decode("Arial-BOLD-64") with a relatively short text:
"LA CLAPI\u00c8RE \nAlt: 1100-1700m \nGlissement de terrain majeur dans la haute
Tin\u00e9e, sur un flanc du Parc du Mercantour."

Comment by kbr [ 09/Nov/07 ]

Recent regression in the TextRenderer causing ArrayIndexOutOfBoundsException on
the attached test case:
http://www.javagaming.org/forums/index.php?topic=15594.90

Comment by kbr [ 09/Nov/07 ]

Fixed four issues:

  • Regression in new segmenting and punting code causing
    ArrayIndexOutOfBoundsException due to not resetting the glyph
    uploader during punt.
  • Issue in same code where length and total advance were not being
    reset properly.
  • Incorrect handling in glyph-by-glyph rendering when backing store
    was using NPOT texture and GL_ARB_texture_rectangle.
  • Failure to punt when glyph code was out of bounds.

Checked in two regression tests for these issues.





[JOGL-331] Floating-point precision needed in TextRenderer Created: 29/Oct/07  Updated: 08/Nov/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Issuezilla Id: 331

 Description   

Patrick Murris from the NASA World Wind Java project has pointed out that for
high-quality rendering of text it is necessary to use floating-point precision
rather than integer precision. The Rectangle2D from getBounds() needs to not be
rounded to an integer size, and draw() needs an overloading taking a
floating-point x and y.



 Comments   
Comment by kbr [ 08/Nov/07 ]

More details from Patrick on related usage, which may inform changes to the
Javadoc of the getBounds() method:

"The trick to get the most accurate advance measurements is:
1. avoid cumulating text chunks bounds width. They get rounded to int and errors
sum up. Reevaluate all previous chunks in one getBounds() to eliminate
cumulative errors.
2. use the getBounds() rectangle x and y properties to compute advance for one
chunk. Advance on x is bounds.getWidth() plus bounds.getX(). This way, leading
spaces are almost correctly accounted for.

This gives very acceptable results for word by word processing.

However, the one limitating thing i see here is the rounding to int of all draw
and getBounds coordinates. Allowing floats or doubles would ease the above point
one."





[JOGL-328] jogl binary for windows xp x64 Created: 25/Oct/07  Updated: 29/Oct/07  Resolved: 29/Oct/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: alimuhnresearchca Assignee: jogl-issues
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: PC


Issuezilla Id: 328

 Description   

I am unable to run the jogl demos on my Windows XP x64 OS on my amd64 system
using the files in jogl-1.1.0-windows-amd64.zip. I get a
java.lang.UnsatisfiedLinkError with this message: "This application has failed
to start because the application configuration is incorrect. Reinstalling the
application may fix this problem"
The paths to jogl.dll, jogl.jar and gluegen-rt.jar have all been specified.

Here is the exact command I run in my Windows command prompt and the error
message I get (I have the gluegen-rt.dll, jogl.dll, jogl_awt.dll and jogl_cg.dll
files in current directory):
"C:\Program Files\Java\jdk1.6.0_03\bin\java.exe" -cp
"./jogl-demos-data.jar;./jogl-demos-util.jar;./jogl-demos.jar;./jogl.jar;./gluegen-rt.jar"
-Djava.library.path="." -Dsun.java2d.noddraw=true demos.gears.Gears
Exception in thread "main" java.lang.UnsatisfiedLinkError:
Z:\tools\NavigatorGL_auxiliaryFiles\libs\ThirdParty\jogl-april22-2007\jogl-1.1.0-windows-amd64\jogl.dll:
This application has failed to start because the application configuration is
incorrect. Reinstalling the application may fix this problem
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at
com.sun.opengl.impl.NativeLibLoader$DefaultAction.loadLibrary(NativeLibLoader.java:78)
at com.sun.opengl.impl.NativeLibLoader.loadLibrary(NativeLibLoader.java:101)
at com.sun.opengl.impl.NativeLibLoader.access$100(NativeLibLoader.java:47)
at com.sun.opengl.impl.NativeLibLoader$1.run(NativeLibLoader.java:109)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.opengl.impl.NativeLibLoader.loadCore(NativeLibLoader.java:107)
at
com.sun.opengl.impl.windows.WindowsGLDrawableFactory.<clinit>(WindowsGLDrawableFactory.java:60)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at
javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:106)
at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:113)
at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:82)
at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:75)
at demos.gears.Gears.main(Gears.java:19)

Using the rc6 release gives the same error.



 Comments   
Comment by kbr [ 29/Oct/07 ]

I verified that at least the nightly build of JOGL for Windows/AMD64 is working
properly on Windows XP Professional 64. You are probably mixing a 32-bit JRE
with 64-bit JOGL libraries.





[JOGL-330] Inconsistent handling of spaces in TextRenderer Created: 29/Oct/07  Updated: 29/Oct/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Issuezilla Id: 330

 Description   

Patrick Murris from the NASA World Wind Java project reports that the
TextRenderer is returning inconsistent results for both strings with leading and
trailing spaces as well as the empty string:

"""
I have been putting together a very very simple html support to produce some
'moderatly wealthy' text... and i had to struggle and work around a couple
unexpected behaviors of getBounds():

1. getBounds() ignores leading and trailing spaces - draw doesnt.
2. getBounds("") does return a width of 2 pixels (Arial 12 plain) - draw paints
nothing.

I would have expected getBounds() and draw() to follow the same metric and refer
to the same bounds for the same string.
Is there something i am misunderstanding about space handling and empty strings ?
"""






[JOGL-327] Add ability to draw bounding rectangle to TextRenderer Created: 23/Oct/07  Updated: 23/Oct/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Issuezilla Id: 327

 Description   

The NASA World Wind Java project needs the ability to select text based on mouse
clicks. Their selection scheme is based on colors: they draw each selectable
item in the scene with a different color and then map back the color under the
mouse pointer to the object.

If the TextRenderer had the ability to draw the bounding rectangle of the text
instead of the text itself, this would allow this sort of selection scheme to be
used by applications. The application could even choose a different color for
each glyph to support letter-by-letter selection.






[JOGL-325] JOGL applets leave trails when scrolled Created: 19/Oct/07  Updated: 19/Oct/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC
URL: http://www.javagaming.org/forums/index.php?topic=17550.0


Issuezilla Id: 325

 Description   

When a web page containing a JOGL applet is scrolled on some machines and
operating systems, it leaves trails behind. This makes it difficult if not
impossible to build web based applications with JOGL.

This problem has been seen on multiple operating systems and web browsers, but
the URL above indicates that the problem may be limited to the Firefox and
Safari browsers. The problem is reproducible on Firefox 2 and 3 on Windows with
certain graphics hardware and on Safari on Mac OS X again with certain graphics
hardware. Notably the problem does not occur in Internet Explorer.

When this problem was first reported it appeared that it might be a bug in
NVidia's drivers, but a bug filed with them was closed with the indication that
the trails occurred with ATI hardware as well.

Investigation is needed to see whether the setting of the window style performed
by the Java Plug-In affects the behavior in any way. The window styles set by
the IE and Firefox plug-ins are currently different.

A bug should probably be filed with Apple.






[JOGL-241] Graphics Device error on dual-monitor setup Created: 31/Jul/06  Updated: 18/Oct/07  Resolved: 18/Oct/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: thomahawk Assignee: jogl-issues
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 241

 Description   

Receive the following error:

java.lang.IllegalArgumentException: adding a container to a container on a
different GraphicsDevice
at java.awt.Component.checkGD(Component.java:858)
at java.awt.Container.addImpl(Container.java:1015)
at java.awt.Container.add(Container.java:899)
at demos.applets.GearsApplet.init(GearsApplet.java:22)
at
com.sun.opengl.util.JOGLAppletLauncher.startSubApplet(JOGLAppletLauncher.java:721)
at com.sun.opengl.util.JOGLAppletLauncher.access$700(JOGLAppletLauncher.java:117)
at com.sun.opengl.util.JOGLAppletLauncher$2.run(JOGLAppletLauncher.java:685)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

...when I open firefox on a dual-monitor setup and move the firefox window onto
the second monitor. Applications load by default onto the first monitor, so I
can't find any workaround to make JOGL work on the second monitor.



 Comments   
Comment by kbr [ 18/Oct/07 ]

This has been fixed under Issue 316.

      • This issue has been marked as a duplicate of 316 ***




[JOGL-316] Multi-Head issues, identical to issue 241 Created: 07/Sep/07  Updated: 18/Oct/07  Resolved: 18/Oct/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Blocker
Reporter: moorej Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Attachments: Text File jogl-1.1.1-issue-316.patch     Java Source File JOGLWithNVidiaTwinView.java    
Issuezilla Id: 316

 Description   

Basically, I am creating a JFrame and adding a GLCanvas to it. This sometimes
fails due to java.awt.Component.checkGD() throwing an IllegalArgumentException.
This appears to be due to the fact that the GLCanvas and the JFrame have
different GraphicsDevice instances associated with them. Component.checkGD()
simply checks the id string associated with the device for equality:

void checkGD(String stringID) {
if (graphicsConfig != null) {
if (!graphicsConfig.getDevice().getIDstring().equals(stringID))

{ throw new IllegalArgumentException( "adding a container to a container on a different GraphicsDevice"); }

}
}

On my system (back when I had two heads...) I was using NVidia's driver
(currently 100.14.11) in TwinView mode with Xorg (7.0, 7.1) on Linux 2.6.22-x64,
I see two GraphicsDevices, one corresponding to each head. These have ID
strings something like ':0.0' and ':0.1' respectively.

It may be possible to work around the problem by detecting the graphics device
used by the container I am adding the GLCanvas to, and setting the GC on the
GLCanvas (during construction?), however, since the GLCanvas seems to work fine
when moving the canvas (and parent container) across heads, I suspect that it
may be possible to solve this within JOGL...

The attached code can be compiled (with jogl/gluegen-rt in the classpath) and
run with no arguments. It will attempt to identify a pair of GraphicsDevices
that have identical id strings, except for the last part. If successful, it
will open a JFrame on one of them, and attempt to add a GLCanvas. If no
exception is thrown, it will move the JFrame to the other head and try to add
another GLCanvas. This reliably demonstrates the issue on my system.

FILE : JOGLWithNVidiaTwinView.java

import java.awt.EventQueue;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.Rectangle;
import java.awt.event.ComponentAdapter;
import java.awt.event.ComponentEvent;
import java.awt.event.ComponentListener;
import java.awt.event.ContainerAdapter;
import java.awt.event.ContainerEvent;
import java.awt.event.ContainerListener;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import java.awt.event.WindowListener;

import javax.media.opengl.GLCanvas;
import javax.swing.JFrame;

/**

  • Class to exhibit issue with JOGL on Linux/Xorg/NVidia/TwinView.
  • This will cause an IllegalArgumentException to be thrown when adding a
    GLCanvas to
  • a JFrame (the JFrame's content pane):
  • java.lang.IllegalArgumentException: adding a container to a container on a
    different GraphicsDevice
    at java.awt.Component.checkGD(Component.java:965)
    at java.awt.Container.addImpl(Container.java:1027)
    at java.awt.Container.add(Container.java:352)
    at JOGLWithNVidiaTwinView$2.run(JOGLWithNVidiaTwinView.java:88)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
    at
    java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
    at
    java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
    at
    java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
    */
    public class JOGLWithNVidiaTwinView {

/**

  • @param args Not used
    */
    public static void main(String[] args) {
    final XScreenDevice[] twinViewPair = XScreenDevice.findTwinViewScreens();
    if (twinViewPair == null) { System.out.println("No TwinView screen pair was found, exiting."); System.exit(1); }

/*

  • Create a new Window on one head.
    */
    final JFrame frame = new
    JFrame(twinViewPair[0].device.getDefaultConfiguration());
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.setSize(200, 200);
    /*
  • Set the frame visible. We will wait until the window is opened before
  • moving it.
    */
    try { openAndWait(frame); System.out.println("Frame is on device with ID: " + frame.getGraphicsConfiguration().getDevice().getIDstring()); System.out.flush(); addCanvas(frame); System.out.println("Moving window to second device..."); System.out.flush(); /* * Get the bounds of the second device and move the frame there. */ final Rectangle secondDeviceBounds = twinViewPair[1].device.getDefaultConfiguration().getBounds(); moveTo(frame, secondDeviceBounds); System.out.println("Frame is on device with ID: " + frame.getGraphicsConfiguration().getDevice().getIDstring()); System.out.println("Adding GLCanvas..."); System.out.flush(); addCanvas(frame); }

    catch (InterruptedException ie)

    { System.out.println("Interrupted..."); }

    }

/**

  • Creates and adds a new GLCanvas to the specified JFrame, blocking
  • until the operation is complete (do not call this from the Event Thread)
  • @param frame
  • @throws InterruptedException
    */
    static void addCanvas(final JFrame frame) throws InterruptedException {
    final boolean[] added = new boolean[] { false }

    ;
    final GLCanvas canvas = new GLCanvas();
    final ContainerListener listener = new ContainerAdapter() {

@Override
public void componentAdded(ContainerEvent e) {
if (e.getComponent() == canvas) {
synchronized (added)

{ added[0] = true; added.notifyAll(); }

}
}

};
EventQueue.invokeLater(new Runnable() {

public void run() {
final GLCanvas canvas = new GLCanvas();
try

{ frame.getContentPane().add(canvas); }

catch (IllegalArgumentException iae)

{ System.out.println("Caught exception while adding canvas: "); System.out.flush(); iae.printStackTrace(); }

}
});
try {
synchronized (added)

{ while (!added[0]) added.wait(); }

} finally

{ frame.removeContainerListener(listener); }

}

/**

  • Moves the specified frame somewhere (top-left corner) of the specified
    rectangle, blocking until
  • the operation is complete (do not call this from the Event Thread).
  • @param frame
  • @param target
  • @throws InterruptedException
    */
    static void moveTo(final JFrame frame, final Rectangle target) throws
    InterruptedException {
    final boolean[] moved = new boolean[] { target.contains(frame.getX(), frame.getY(), frame.getWidth(), frame .getHeight()) }

    ;
    final ComponentListener listener = new ComponentAdapter() {

public void componentMoved(ComponentEvent e) {
synchronized (moved) {
if (moved[0] = target.contains(frame.getX(), frame.getY(),
frame.getWidth(), frame.getHeight()))

{ moved.notifyAll(); System.out.println("Moved to: " + frame.getX() + ", " + frame.getY()); }

else

{ System.out.println("Moved somewhere unexpected: " + frame.getX() + ", " + frame.getY()); }

}
}
};
frame.addComponentListener(listener);
EventQueue.invokeLater(new Runnable() {

public void run()

{ frame.setLocation(target.x, target.y); }

});
try {
synchronized (moved)

{ while (!moved[0]) moved.wait(); }

} finally

{ frame.removeComponentListener(listener); }

}

/**

  • Sets the specified frame visible and waits for a corresponding WindowEvent.
  • Do not call from Event Thread.
  • @param frame
  • @throws InterruptedException
    */
    static void openAndWait(JFrame frame) throws InterruptedException {
    final boolean[] open = new boolean[] { frame.isVisible() }

    ;
    final WindowListener listener = new WindowAdapter() {

public void windowOpened(WindowEvent e) {
synchronized (open)

{ open[0] = true; open.notifyAll(); }

}
};
frame.addWindowListener(listener);
frame.setVisible(true);
try {
synchronized (open)

{ while (!open[0]) open.wait(); }

} finally

{ frame.removeWindowListener(listener); }

}

/**

  • Class to extract some (Unix, or possible Linux-specific)
  • info from a GraphicsDevice instance's idString.
    */
    static class XScreenDevice {

public final GraphicsDevice device;
public final String hostName;
public final String serverID;
public final String displayID;

public XScreenDevice(GraphicsDevice device) {
this.device = device;
String idStr = device.getIDstring();

final int colonIdx = idStr.indexOf(':');
if (colonIdx < 0)

{ throw new IllegalArgumentException("The specified device (id: " + idStr + ") does not appear to be an X screen device."); }

hostName = idStr.substring(0, colonIdx);

idStr = idStr.substring(colonIdx + 1);
final int dotIdx = idStr.indexOf('.');
if (dotIdx < 0)

{ displayID = ""; serverID = idStr; }

else

{ serverID = idStr.substring(0, dotIdx); displayID = idStr.substring(dotIdx + 1); }

}

/**

  • Checks whether the specified device might be involved in a TwinView
  • configuration with this device. This means that the hostNames and
  • serverIDs must be identical, and the displayID and device must be
  • different.
  • @param device A non-null XScreenDevice.
  • @return <code>true</code> if the specified device is (probably) in
  • a TwinView configuration with this device, false otherwise.
    */
    public boolean isTwinViewComplement(XScreenDevice device) { return device.device != this.device && device.hostName.equals(this.hostName) && device.hostName.equals(this.hostName) && !device.displayID.equals(this.displayID); }

public String toString()

{ return "X Screen Device -- id: " + device.getIDstring() + " (host=" + hostName + ", serverID=" + serverID + ", displayID=" + displayID + ")"; }

/**

  • Identifies a pair of TwinView screens in the local graphics
  • environment. A TwinView pair (for the purposes of this method) has X
  • display IDs comprised of identical hostnames, followed by a colon,
  • identical server ids, followed by a '.', and unique display ids. For
  • example, ':0.0' and ':0.1' would be a pair.
  • @return A pair of XScreenDevice instances representing two distinct
  • GraphicsDevices in the local environment that are believed to
  • be a TwinView pair, or null if none are found.
    */
    public static XScreenDevice[] findTwinViewScreens() {
    final GraphicsEnvironment graphicsEnv =
    GraphicsEnvironment.getLocalGraphicsEnvironment();
    final GraphicsDevice[] screenDevices = graphicsEnv.getScreenDevices();
    if (screenDevices == null || screenDevices.length < 2) { /* * Not enough devices for a TwinView pair. */ return null; }

    for (int firstScreenIdx = 1; firstScreenIdx < screenDevices.length;
    firstScreenIdx++) {
    final XScreenDevice firstDevice;
    try

    { firstDevice = new XScreenDevice(screenDevices[firstScreenIdx]); System.out.println("Searching for TwinView complement to: " + firstDevice); }

    catch (IllegalArgumentException iae)

    { System.out.println("Device: " + screenDevices[firstScreenIdx].getIDstring() + " does not appear to be an X screen"); continue; }

for (int secondScreenIdx = firstScreenIdx - 1; secondScreenIdx
>= 0; secondScreenIdx--) {
try {
final XScreenDevice secondDevice = new
XScreenDevice(screenDevices[secondScreenIdx]);
System.out.println("\tTesting: " + secondDevice);
if (firstDevice.isTwinViewComplement(secondDevice)) {
System.out.println("TwinView Pair Identified!");
return new XScreenDevice[]

{ firstDevice, secondDevice }

;
}
} catch (IllegalArgumentException iae)

{ /* * Already warned above... */ }

}
}
/*

  • None found.
    */
    return null;
    }
    }
    }


 Comments   
Comment by moorej [ 07/Sep/07 ]

Created an attachment (id=105)
Demo that illustrates TwinView error

Comment by krisher [ 28/Sep/07 ]

Created an attachment (id=106)
Proposed patch to GLCanvas to choose a visual as late as possible, seems to fix checkGD issues on Linux/Xorg/Xinerama.

Comment by kbr [ 18/Oct/07 ]

Thanks for the patch and sorry for not looking into it until now. This fix is
excellent, basically the best that can be done under the circumstances. Fix has
been checked in and will be present in tomorrow's 1.1.1-rc6 build.

Comment by kbr [ 18/Oct/07 ]
      • Issue 241 has been marked as a duplicate of this issue. ***




[JOGL-324] Rendering artifacts with glyph-based TextRenderer Created: 17/Oct/07  Updated: 17/Oct/07  Resolved: 17/Oct/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://www.javagaming.org/forums/index.php?topic=15594.75


Attachments: Java Source File TextTest.java    
Issuezilla Id: 324

 Description   

With the new TextRenderer and certain fonts, rendering artifacts are visible at
small font sizes. The attached test case shows the problem. As of yet the cause
of the problem is unclear. Running with -Djogl.debug.TextRenderer indicates that
the rightmost portion of the characters is being cut off on the backing store.



 Comments   
Comment by kbr [ 17/Oct/07 ]

Changed from using getVisualBounds() to the more accurate
getPixelBounds() when computing bounding box for individual glyphs.

Comment by kbr [ 17/Oct/07 ]

Created an attachment (id=107)
Test case





[JOGL-323] TextRenderer leaves VBOs bound Created: 15/Oct/07  Updated: 17/Oct/07  Resolved: 17/Oct/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: turquoise3232 Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 323

 Description   

User must call following line after end3DRendering
gl.glBindBuffer(GL.GL_ARRAY_BUFFER, 0);

to avoid opengl errors (command not allowed...)

Linux FC 6 with ATIX1600 graphic Card.



 Comments   
Comment by kbr [ 17/Oct/07 ]

Manually unbound VBOs because it appears that some graphics drivers do
not push and pop the GL_ARRAY_BUFFER_BINDING and other state during
glPushClientAttrib / glPopClientAttrib. This is an area where the
OpenGL specification is ambiguous.

Added a non-VBO code path using normal vertex arrays for graphics
cards that don't support VBOs.





[JOGL-322] Please add linker option for vc8 win32 build environment when building gluegen. Created: 10/Oct/07  Updated: 10/Oct/07  Resolved: 10/Oct/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kenchapin Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: Other


Issuezilla Id: 322

 Description   

The file gluegen-cpptasks.xml needs "/NODEFAULTLIB:oldnames.lib" when using vc8
on the win32.msvc is set.

The VC8 product does not have an oldnames.lib.



 Comments   
Comment by kbr [ 10/Oct/07 ]

Added requested linker option. Fix is in gluegen source tree.





[JOGL-321] GL doc could be improved Created: 09/Oct/07  Updated: 10/Oct/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: mbien Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 321

 Description   

The GL interface doc could be improved by adding additional to "Entry point
(through function pointer) to C language function: ..." the doc inside the
OpenGL reference pages (http://www.opengl.org/sdk/docs/man/) for each method.



 Comments   
Comment by kbr [ 09/Oct/07 ]

This is already done for some of the API entry points. See
jogl/make/native-taglet.properties. Please contribute to the project by
expanding the set of functions for which these links are generated.

Comment by mbien [ 10/Oct/07 ]

ah I see, the native-taglet.properties seems to be complete. But currently just
the function headers like void "glAccum(GLenum op, GLfloat value);" are added to
the doc. What about the rest like Parameters, Description, Notes, Errors...? The
important stuff is missing.

Comment by kbr [ 10/Oct/07 ]

These are things that could plausibly be added to the native taglet. The source
code to it is in the GlueGen workspace under src/java/net/highteq/nativetaglet/
. The code which produced the native-taglet.properties (which, by the way, isn't
complete – it only has links for the core OpenGL functions) is I believe in the
GlueGen workspace under make/lib/JOGLDocLinksGeneratorAndLibs.jar .

Any contributions you could make in this area would be welcome.





[JOGL-318] ClassNotFoundException when running applet if JOGL installed into JRE Created: 09/Oct/07  Updated: 10/Oct/07  Resolved: 10/Oct/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Blocker
Reporter: kcr Assignee: kbr
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 318

 Description   

A ClassNotFoundException is thrown when running an applet using
JNLPAppletLauncher on a system where the latest JOGL is installed into the
lib/ext directory of the JRE.

To reproduce this, copy jogl-1.1.1-rc4 into the JRE. Then run the JOGL Applet
Demo at:

https://jogl-demos.dev.java.net/applettest.html

You will get the following exception:

Exception in thread "AWT-EventQueue-2" java.lang.UnsatisfiedLinkError
at
com.sun.gluegen.runtime.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:99)
at com.sun.gluegen.runtime.NativeLibLoader.access$000(NativeLibLoader.java:51)
at com.sun.gluegen.runtime.NativeLibLoader$1.run(NativeLibLoader.java:70)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.gluegen.runtime.NativeLibLoader.loadGlueGenRT(NativeLibLoader.java:68)
at
com.sun.gluegen.runtime.NativeLibrary.ensureNativeLibLoaded(NativeLibrary.java:399)
at com.sun.gluegen.runtime.NativeLibrary.open(NativeLibrary.java:163)
at com.sun.gluegen.runtime.NativeLibrary.open(NativeLibrary.java:129)
at com.sun.opengl.impl.x11.DRIHack.begin(DRIHack.java:109)
at
com.sun.opengl.impl.x11.X11GLDrawableFactory.<clinit>(X11GLDrawableFactory.java:99)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:111)
at javax.media.opengl.GLCanvas.chooseGraphicsConfiguration(GLCanvas.java:409)
at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:117)
at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:86)
at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:79)
at demos.applets.GearsApplet.init(GearsApplet.java:19)
at
org.jdesktop.applet.util.JNLPAppletLauncher.startSubApplet(JNLPAppletLauncher.java:1889)
at
org.jdesktop.applet.util.JNLPAppletLauncher.access$200(JNLPAppletLauncher.java:650)
at org.jdesktop.applet.util.JNLPAppletLauncher$5.run(JNLPAppletLauncher.java:1261)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
Caused by: java.lang.ClassNotFoundException:
org.jdesktop.applet.util.JNLPAppletLauncher
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at
com.sun.gluegen.runtime.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:85)
... 28 more

See also Java 3D issue: https://java3d.dev.java.net/issues/show_bug.cgi?id=534



 Comments   
Comment by kcr [ 09/Oct/07 ]

Evaluation:

The bug is a result of the way the ClassLoader mechanism works in Java. The
loadLibrary method in JOGL essentially does the following, as recommended by the
JNLPAppletLauncher docs:

if (usingJNLPAppletLauncher) {
try

{ // Call JNLPAppletLauncher.loadLibrary method using reflection }

catch (Exception e)

{ throw new UnsatisfiedLinkError... }
} else { System.loadLibrary(libraryName); }

In the case where the JOGL classes are installed into the JRE, the
ExtensionClassLoader will load the installed JOGL classes from lib/ext, causing
them to take precedence over the JOGL classes loaded by Java Plug-in. Because
the JOGL files are loaded by the ExtensionClassLoader and the JNLPAppletLauncher
class file is loaded by the Plug-in ClassLoader, the JOGL classes cannot see the
JNLPAppletLauncher class.

The solution is to fall back to using System.loadLibrary() if loading the
JNLPAppletLauncher class fails with a ClassNotFoundException. This is done as
follows:

boolean loaded = false;
if (usingJNLPAppletLauncher) {
try { // Call JNLPAppletLauncher.loadLibrary method using reflection loaded = true; } catch (Exception e) { // print warning message and continue } catch (Exception e) { throw new UnsatisfiedLinkError... }

}

if (!loaded)

{ System.loadLibrary(libraryName); }
Comment by kcr [ 09/Oct/07 ]

There was a typo in the suggested fix. It should be:

boolean loaded = false;
if (usingJNLPAppletLauncher) {
try

{ // Call JNLPAppletLauncher.loadLibrary method using reflection loaded = true; }

catch (ClassNotFoundException ex)

{ // print warning message and continue }

catch (Exception e)

{ throw new UnsatisfiedLinkError... }

}

if (!loaded)

{ System.loadLibrary(libraryName); }
Comment by kbr [ 10/Oct/07 ]

Putting JOGL into the JRE's lib/ext directory causes huge problems. Among other
things, it prevents us from evolving the JOGL library, because the version
dropped in to the JRE will override any version used by an application deployed
via Java Web Start or an applet.

Java 3D needs to recommend to end users not to drop the Java 3D jars into
jre/lib/ext. We're not going to support that configuration in JOGL.

Marking as "will not fix".

Comment by kcr [ 10/Oct/07 ]

Whether or not you think people should install JOGL into the JRE (and I happen
to agree that it's not the best idea), they are going to do it anyway. Refusing
to fix this bug isn't going to change that, it is instead just going to make it
harder for some people to run JOGL applets – particularly on Apple.

In any case, the choice is: 1) fix this bug and have applets work the same way
as javaws applications; or 2) leave it broken for applets.

Comment by kbr [ 10/Oct/07 ]

People aren't going to put JOGL into the JRE's extensions directory unless
someone advises them to. For the past four years on the JOGL forum and in all of
the JOGL documentation we have advised against this practice, and we do not
support this configuration.

We're not going to put in a workaround to make this seem to work in certain
circumstances. Installing JOGL into jre/lib/ext is not a supported
configuration. If Java 3D requires JOGL to be installed there then either (a)
Java 3D needs to rethink its deployment strategy or (b) Java 3D needs to use a
private copy of JOGL utilizing a different set of namespaces than
javax.media.opengl.* and com.sun.opengl.* to avoid collisions with the mainline
releases of JOGL.





[JOGL-320] improving DebugGL Created: 09/Oct/07  Updated: 09/Oct/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: mbien Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 320

 Description   

DebugGL could add additional checks to some methods.
e.g:
bounds checks for methods containing Buffers and indices as arguments (causing
often VM crash if out of bounds or not rewinded - and a lot of confusion for
beginners)



 Comments   
Comment by kbr [ 09/Oct/07 ]

Agreed. It would be helpful if you could look into enhancing GlueGen or the
BuildComposablePipeline class to autogenerate these kinds of range checks. There
are already some range checks for the simple cases, but I agree that more are
needed for best behavior. However it will be a while before the JOGL development
team has time to investigate this.





[JOGL-319] JOGL components crash if used inside an NetBeans module Created: 09/Oct/07  Updated: 09/Oct/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: mbien Assignee: jogl-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 319

 Description   

The usage of Beans.isDesignTime() is not safe for JOGL components. They assume
to be inside the NetBeans FormDesigner if Beans.isDesignTime() returns true. But
true is also returned if they are used by a module inside NetBeans.



 Comments   
Comment by mbien [ 09/Oct/07 ]

We call in the NetBeans OpenGL Pack Beans.setDesignTime(false) before rendering
to workaround that issue. This is no solution because it also crashes while a
JOGL component is inside the FormDesigner.

Comment by kbr [ 09/Oct/07 ]

Please investigate this issue further and suggest a fix. We on the JOGL
development team have neither the expertise nor the time at the moment to
investigate a more complete solution. We have heard something about providing
another bean to be used in this case; see Issue 254.





[JOGL-304] TextRenderer rendering artifacts in 3D mode Created: 11/Jun/07  Updated: 08/Oct/07  Resolved: 08/Oct/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun
URL: http://www.javagaming.org/forums/index.php?topic=16865.0


Issuezilla Id: 304

 Description   

There are rendering artifacts showing up when the TextRenderer is used in 3D
mode probably caused by newer graphics cards using more than just the adjacent
pixels for interpolation. Should increase the spacing between adjacent strings
on the backing store and make sure the entire area is cleared.



 Comments   
Comment by campbell [ 26/Jul/07 ]

I'd expect this bug to be just as reproducible on old hardware as well. GL_LINEAR filtering should/will only
ever access one more texel in any given direction. So as long as you allow for one blank (all zeros) row/
column between adjacent strings, and you use GL_CLAMP_TO_EDGE for the texture wrap mode (to handle
the edge cases), the suggested fix should work well.

Comment by kbr [ 08/Oct/07 ]

Integrated John Burkey's new TextRenderer implementation using
glyph-by-glyph caching for most cases, with fallbacks to
String-by-String caching for complete Unicode correctness. New
implementation yields drastic performance improvements for
applications displaying large amounts of dynamic text. Upgraded JOGL
demos to work with new TextRenderer.

This checkin fixes at least the following issues:

Issue 261: Throttle shrinking of backing store texture for TextRenderer
Issue 293: TextRenderer: width of strings with spaces not correct in RC4
Issue 294: TextRenderer: rendering stops when a string is wider than the maximum
texture size
Issue 304: TextRenderer rendering artifacts in 3D mode

as well as outstanding performance issues with the current
TextRenderer reported on the JOGL forum.





[JOGL-294] TextRenderer: rendering stops when a string is wider than the maximum texture size Created: 18/Apr/07  Updated: 08/Oct/07  Resolved: 08/Oct/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: emzic Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 294

 Description   

Hello,
when the TextRenderer should draw a string without spaces that is wider than
the maximum texture size, the rendering just stops and the application freezes.

if needed i could provide a testcase, but it will be dependend on the graphics
hardware of course.

thanks.



 Comments   
Comment by kbr [ 08/Oct/07 ]

Integrated John Burkey's new TextRenderer implementation using
glyph-by-glyph caching for most cases, with fallbacks to
String-by-String caching for complete Unicode correctness. New
implementation yields drastic performance improvements for
applications displaying large amounts of dynamic text. Upgraded JOGL
demos to work with new TextRenderer.

This checkin fixes at least the following issues:

Issue 261: Throttle shrinking of backing store texture for TextRenderer
Issue 293: TextRenderer: width of strings with spaces not correct in RC4
Issue 294: TextRenderer: rendering stops when a string is wider than the maximum
texture size
Issue 304: TextRenderer rendering artifacts in 3D mode

as well as outstanding performance issues with the current
TextRenderer reported on the JOGL forum.





[JOGL-293] TextRenderer: width of strings with spaces not correct in RC4 Created: 18/Apr/07  Updated: 08/Oct/07  Resolved: 08/Oct/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: emzic Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://www.embege.com/misc/textrenderer.zip


Issuezilla Id: 293

 Description   

hello, i noticed that the calculated width of strings via getBounds() is not
exactly the real width that is drawn on the texture. i believe it has something
to do with the spacewidth in RC4, since in RC3 this works fine.

here is a testcase that demonstrates the difference betweeen RC3 and RC4:

http://www.embege.com/misc/textrenderer.zip

just two classes, should compile fine with RC3 and RC4.
just type something with spaces in the red line and then use the mouse to
position the cursor. you should see that the cursor behaves correctly in RC3
and is off by some pixels in RC4.

thanks a lot!



 Comments   
Comment by kbr [ 08/Oct/07 ]

Integrated John Burkey's new TextRenderer implementation using
glyph-by-glyph caching for most cases, with fallbacks to
String-by-String caching for complete Unicode correctness. New
implementation yields drastic performance improvements for
applications displaying large amounts of dynamic text. Upgraded JOGL
demos to work with new TextRenderer.

This checkin fixes at least the following issues:

Issue 261: Throttle shrinking of backing store texture for TextRenderer
Issue 293: TextRenderer: width of strings with spaces not correct in RC4
Issue 294: TextRenderer: rendering stops when a string is wider than the maximum
texture size
Issue 304: TextRenderer rendering artifacts in 3D mode

as well as outstanding performance issues with the current
TextRenderer reported on the JOGL forum.





[JOGL-261] Throttle shrinking of backing store texture for TextRenderer Created: 17/Jan/07  Updated: 08/Oct/07  Resolved: 08/Oct/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun
URL: http://www.javagaming.org/forums/index.php?topic=15634.30


Attachments: Java Source File TextFlow.java    
Issuezilla Id: 261

 Description   

bienator on the javagaming.org forums has pointed out that the TextRenderer's
backing store sometimes changes size too quickly. A suggestion is to throttle
the rate at which the backing store texture can be shrunk.



 Comments   
Comment by bienator [ 18/Jan/07 ]

Created an attachment (id=88)
modified TextFlow demo

Comment by kbr [ 08/Oct/07 ]

Integrated John Burkey's new TextRenderer implementation using
glyph-by-glyph caching for most cases, with fallbacks to
String-by-String caching for complete Unicode correctness. New
implementation yields drastic performance improvements for
applications displaying large amounts of dynamic text. Upgraded JOGL
demos to work with new TextRenderer.

This checkin fixes at least the following issues:

Issue 261: Throttle shrinking of backing store texture for TextRenderer
Issue 293: TextRenderer: width of strings with spaces not correct in RC4
Issue 294: TextRenderer: rendering stops when a string is wider than the maximum
texture size
Issue 304: TextRenderer rendering artifacts in 3D mode

as well as outstanding performance issues with the current
TextRenderer reported on the JOGL forum.





[JOGL-317] GLJPanel handleReshape bug Created: 02/Oct/07  Updated: 02/Oct/07  Resolved: 02/Oct/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Task Priority: Blocker
Reporter: himuro Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 317

 Description   

Hi.

I found a wrong algorithm in GLJPanel.
This code recreate pbuffer but judge algorithm is wrong.


[version] jogl-1.1.1-rc3
[src] GLJPanel.java
[line] 967-968

if ((panelWidth > pbufferWidth ) || (panelHeight >
pbufferHeight) ||
(panelWidth < (pbufferWidth / shrinkFactor)) || (panelHeight <
(pbufferWidth / shrinkFactor))) {


in last statement
[wrong] (panelHeight < (pbufferWidth / shrinkFactor)
[right] (panelHeight < (pbufferHeight / shrinkFactor)

Please correct source.

Thanks.


--------------------------------------------------
Denso IT Laboratory, Inc.
Keisuke UTO
E-mail: kuto@d-itlab.co.jp
--------------------------------------------------



 Comments   
Comment by kbr [ 02/Oct/07 ]

Fixed obvious bug in algorithm as per submitter's comment. Fix will be present
in nightly builds dated 10/3 and later. Thanks for the patch.





[JOGL-315] Memory Leak with Overlay Created: 03/Sep/07  Updated: 18/Sep/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jlhider Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 315

 Description   

When using an Overlay object to create a graphics context to paint with Java2D,
calling dispose on the graphics context is not enough - the underlying
TextureRenderer dispose method should also be invoked. However, the Overlay
class does not expose a mechanism to invoke the TextureRenderer dispose. The
result is a rapid consumption of memory.
The following snippet shows the basic GLEventListener I used to render the
overlay in a loop cycle - no actual painting is necessary to consume memory.

public CustomGLEventListener implements GLEventListener {

public void display(GLAutoDrawable drawable) {
Overlay overlay = new Overlay(drawable);
Graphics2D g = overlay.createGraphics();
// paint(g); // painting goes here
g.dispose();

overlay.drawAll();
//overlay.dispose(); // Recommended addition
}

public void displayChanged(GLAutoDrawable drawable, boolean modeChanged,
boolean deviceChanged)

{ /* NOOP */ }
public void init(GLAutoDrawable drawable) { /* NOOP */ }

public void reshape(GLAutoDrawable drawable, int x, int y, int width, int
height)

{ /* NOOP */ }

}

Adding the following method to the com.sun.opengl.util.j2d.Overlay class and
invoking it when the overlay is no longer needed appears to resolve the memory
consumption problem:
public void dispose() {
renderer.dispose();
}

I expect subsequent calls to the overlay object after dispose is invoked will
throw a NullPointerException (such as if createGraphics were to be called).



 Comments   
Comment by kbr [ 17/Sep/07 ]

This isn't the recommended usage style for the Overlay. You're supposed to
create it once in your init() method and use it many times in your display
callback. See demos.j2d.TestOverlay in the jogl-demos workspace.

I agree that for completeness a dispose() call should probably be added, but
this is really more a bug in the application and not in JOGL.

Comment by jlhider [ 18/Sep/07 ]

Understood. The example was simply to demonstrate the condition where if you
stop using an overlay (and discard it), there is a risk of creeping memory
consumption. It would not likely be noticed during quick development test runs
or for short running apps, but could reveal itself in long runs of dynamic apps
(or in a brutal case such as the example). If during some point in the
application I want to use one or more overlays (for whatever reason), I should
be able to release them during the spans of time that they are not needed.

That's all.
Thanks





[JOGL-299] Parameter passing to subapplets of JoglAppletLauncher Created: 03/May/07  Updated: 17/Sep/07  Resolved: 17/Sep/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: godji Assignee: jogl-issues
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 299

 Description   

Currently JoglAppletLauncher does not suport passing parameters to the
unsigned subapplet it launches. It would be extremely useful to be able to
say, in the HTML that invokes JoglAppletLauncher, something like:

<param name="subapplet.param.param0" value="value0">
<param name="subapplet.param.param1" value="value1">
...
etc.

Correct me if I'm wrong, but that should only require a simple modification of
the JoglAppletLauncher initalization code as well as it's subapplet proxy.

Thanks!



 Comments   
Comment by kbr [ 03/May/07 ]

Could you prototype this and provide a suggested patch? That would be very
helpful and would accelerate the incorporation of this functionality.

Comment by kbr [ 17/Sep/07 ]

I believe this bug report is incorrect and that the parameters specified for the
JOGLAppletLauncher are passed down to the sub-applet. At least, it has been
confirmed by a JOGL user that the new JNLPAppletLauncher (which uses the same
mechanism in this area as the JOGLAppletLauncher) works in this fashion. Closing
as "works for me".





[JOGL-311] Unable to make context current and crashes vm when useing release and rc3 Created: 05/Aug/07  Updated: 07/Aug/07

Status: Reopened
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Trivial
Reporter: badapple Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 311

 Description   

Receiving "Exception in thread "AWT-EventQueue-0"
javax.media.opengl.GLException: Error making context current" in the current
release and the release candidate when using GLJPanel. This was solved in
earlier JSR-231 releases. This seems to only happen when using a GLJPanel. I
also tried with the JOGL RC3 and it crashes the JVM. I have included the vm
error log next.
**********************************************************************************
#

  1. An unexpected error has been detected by Java Runtime Environment:
    #
  2. SIGSEGV (0xb) at pc=0xb535a317, pid=20461, tid=2954005392
    #
  3. Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode, sharing)
  4. Problematic frame:
  5. C [libX11.so.6+0x32317] XQueryExtension+0x17
    #
  6. If you would like to submit a bug report, please visit:
  7. http://java.sun.com/webapps/bugreport/crash.jsp
    #

--------------- T H R E A D ---------------

Current thread (0x0848b800): JavaThread "AWT-EventQueue-0" [_thread_in_native,
id=20481]

siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x000004d0

Registers:
EAX=0xb44f80ad, EBX=0xb5415b2c, ECX=0x084bc7a8, EDX=0x00000000
ESP=0xb0127570, EBP=0xb01275b8, ESI=0x00000000, EDI=0x00000000
EIP=0xb535a317, CR2=0x000004d0, EFLAGS=0x00010282

Top of Stack: (sp=0xb0127570)
0xb0127570: b7f20150 00001ae0 00000000 00000001
0xb0127580: b0127634 0848b800 b0127724 b01275ac
0xb0127590: 063057d8 b0127704 b01275e0 b0127634
0xb01275a0: 0848b800 00000000 00000000 b5415b2c
0xb01275b0: 00000000 00000000 b01275f8 b534ec6b
0xb01275c0: 00000000 b44f80ad b01275e0 b01275e4
0xb01275d0: b01275e8 b7f20120 0848b800 b01275f8
0xb01275e0: b7e4b60e b7f20120 00000010 b5838158

Instructions: (pc=0xb535a317)
0xb535a307: ec 3c 8b 7d 08 e8 36 51 fe ff 81 c3 1b b8 0b 00
0xb535a317: 8b 87 d0 04 00 00 85 c0 74 05 89 3c 24 ff 10 8b

Stack: [0xb00d8000,0xb0129000), sp=0xb0127570, free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libX11.so.6+0x32317] XQueryExtension+0x17
C [libX11.so.6+0x26c6b] XInitExtension+0x3b
C [libXext.so.6+0xc433] XextAddDisplay+0x53
C [libGL.so.1+0x20704]
C [libGL.so.1+0x20f64] __glXInitialize+0x14
C [libGL.so.1+0x21f6f] __glXSetupForCommand+0x3f
C [libGL.so.1+0x2020b]
C [libjogl.so+0x48bf1] Java_com_sun_opengl_impl_x11_GLX_glXDestroyContext__JJ+0x3e
j com.sun.opengl.impl.x11.GLX.glXDestroyContext(JJ)V+0
j com.sun.opengl.impl.x11.X11GLContext.destroyImpl()V+78
j com.sun.opengl.impl.GLContextImpl.destroy()V+60
j javax.media.opengl.GLJPanel.removeNotify()V+77
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j javax.swing.JRootPane.removeNotify()V+5
j java.awt.Container.removeNotify()V+38
j java.awt.Window.removeNotify()V+16
j java.awt.Frame.removeNotify()V+51
j java.awt.Window$1DisposeAction.run()V+137
j java.awt.Window.doDispose()V+16
j java.awt.Window.dispose()V+1
j org.davincisoft.DaVinci.cleanUp()V+28
j org.davincisoft.DaVinci.windowClosing(Ljava/awt/event/WindowEvent;)V+11
j java.awt.AWTEventMulticaster.windowClosing(Ljava/awt/event/WindowEvent;)V+8
j java.awt.AWTEventMulticaster.windowClosing(Ljava/awt/event/WindowEvent;)V+8
j java.awt.Window.processWindowEvent(Ljava/awt/event/WindowEvent;)V+68
j javax.swing.JFrame.processWindowEvent(Ljava/awt/event/WindowEvent;)V+2
j java.awt.Window.processEvent(Ljava/awt/AWTEvent;)V+69
j java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+562
j java.awt.Container.dispatchEventImpl(Ljava/awt/AWTEvent;)V+42
j java.awt.Window.dispatchEventImpl(Ljava/awt/AWTEvent;)V+19
j java.awt.Component.dispatchEvent(Ljava/awt/AWTEvent;)V+2
j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+46
j java.awt.EventDispatchThread.pumpOneEventForFilters(I)Z+156
j
java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+30
j
java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j java.awt.EventDispatchThread.run()V+9
v ~StubRoutines::call_stub
V [libjvm.so+0x20967d]
V [libjvm.so+0x3057d8]
V [libjvm.so+0x208f90]
V [libjvm.so+0x20901d]
V [libjvm.so+0x279215]
V [libjvm.so+0x38035f]
V [libjvm.so+0x3066b3]
C [libpthread.so.0+0x531b]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.sun.opengl.impl.x11.GLX.glXDestroyContext(JJ)V+0
j com.sun.opengl.impl.x11.X11GLContext.destroyImpl()V+78
j com.sun.opengl.impl.GLContextImpl.destroy()V+60
j javax.media.opengl.GLJPanel.removeNotify()V+77
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j javax.swing.JRootPane.removeNotify()V+5
j java.awt.Container.removeNotify()V+38
j java.awt.Window.removeNotify()V+16
j java.awt.Frame.removeNotify()V+51
j java.awt.Window$1DisposeAction.run()V+137
j java.awt.Window.doDispose()V+16
j java.awt.Window.dispose()V+1
j org.davincisoft.DaVinci.cleanUp()V+28
j org.davincisoft.DaVinci.windowClosing(Ljava/awt/event/WindowEvent;)V+11
j java.awt.AWTEventMulticaster.windowClosing(Ljava/awt/event/WindowEvent;)V+8
j java.awt.AWTEventMulticaster.windowClosing(Ljava/awt/event/WindowEvent;)V+8
j java.awt.Window.processWindowEvent(Ljava/awt/event/WindowEvent;)V+68
j javax.swing.JFrame.processWindowEvent(Ljava/awt/event/WindowEvent;)V+2
j java.awt.Window.processEvent(Ljava/awt/AWTEvent;)V+69
j java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+562
j java.awt.Container.dispatchEventImpl(Ljava/awt/AWTEvent;)V+42
j java.awt.Window.dispatchEventImpl(Ljava/awt/AWTEvent;)V+19
j java.awt.Component.dispatchEvent(Ljava/awt/AWTEvent;)V+2
j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+46
j java.awt.EventDispatchThread.pumpOneEventForFilters(I)Z+156
j
java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+30
j
java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j java.awt.EventDispatchThread.run()V+9
v ~StubRoutines::call_stub

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
=>0x0848b800 JavaThread "AWT-EventQueue-0" [_thread_in_native, id=20481]
0x0842fc00 JavaThread "Timer-0" [_thread_blocked, id=20480]
0x08413400 JavaThread "TimerQueue" daemon [_thread_blocked, id=20479]
0x08058c00 JavaThread "DestroyJavaVM" [_thread_blocked, id=20465]
0x082a2000 JavaThread "AWT-Shutdown" [_thread_blocked, id=20475]
0x0829f400 JavaThread "AWT-XAWT" daemon [_thread_blocked, id=20474]
0x08282000 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=20473]
0x0808dc00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=20471]
0x0808c400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=20470]
0x0808b000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=20469]
0x08082000 JavaThread "Finalizer" daemon [_thread_blocked, id=20468]
0x08081000 JavaThread "Reference Handler" daemon [_thread_blocked, id=20467]

Other Threads:
0x08077800 VMThread [id=20466]
0x0808f400 WatcherThread [id=20472]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
def new generation total 960K, used 104K [0x8bff0000, 0x8c0f0000, 0x8c4d0000)
eden space 896K, 10% used [0x8bff0000, 0x8c007760, 0x8c0d0000)
from space 64K, 16% used [0x8c0e0000, 0x8c0e2970, 0x8c0f0000)
to space 64K, 0% used [0x8c0d0000, 0x8c0d0000, 0x8c0e0000)
tenured generation total 4096K, used 1396K [0x8c4d0000, 0x8c8d0000, 0x8fff0000)
the space 4096K, 34% used [0x8c4d0000, 0x8c62d2b8, 0x8c62d400, 0x8c8d0000)
compacting perm gen total 12288K, used 2620K [0x8fff0000, 0x90bf0000, 0x93ff0000)
the space 12288K, 21% used [0x8fff0000, 0x9027f338, 0x9027f400, 0x90bf0000)
ro space 8192K, 73% used [0x93ff0000, 0x945ce548, 0x945ce600, 0x947f0000)
rw space 12288K, 57% used [0x947f0000, 0x94ee16c0, 0x94ee1800, 0x953f0000)

Dynamic libraries:
06000000-06412000 r-xp 00000000 07:00 482152
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/libjvm.so
06412000-0642b000 rwxp 00411000 07:00 482152
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/libjvm.so
0642b000-0684a000 rwxp 0642b000 00:00 0
08048000-08052000 r-xp 00000000 07:00 465784
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/bin/java
08052000-08053000 rwxp 00009000 07:00 465784
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/bin/java
08053000-08766000 rwxp 08053000 00:00 0 [heap]
8bff0000-8c0f0000 rwxp 8bff0000 00:00 0
8c0f0000-8c4d0000 rwxp 8c0f0000 00:00 0
8c4d0000-8c8d0000 rwxp 8c4d0000 00:00 0
8c8d0000-8fff0000 rwxp 8c8d0000 00:00 0
8fff0000-90bf0000 rwxp 8fff0000 00:00 0
90bf0000-93ff0000 rwxp 90bf0000 00:00 0
93ff0000-945cf000 r-xs 00001000 07:00 482239
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
945cf000-947f0000 rwxp 945cf000 00:00 0
947f0000-94ee2000 rwxp 005e0000 07:00 482239
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
94ee2000-953f0000 rwxp 94ee2000 00:00 0
953f0000-954c9000 rwxp 00cd2000 07:00 482239
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
954c9000-957f0000 rwxp 954c9000 00:00 0
957f0000-957f4000 r-xs 00dab000 07:00 482239
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
957f4000-95bf0000 rwxp 957f4000 00:00 0
b00d8000-b00db000 ---p b00d8000 00:00 0
b00db000-b0129000 rwxp b00db000 00:00 0
b0129000-b2869000 rwxs ca0c0000 00:0d 17249 /dev/dri/card0
b2869000-b2ea9000 rwxs cc800000 00:0d 17249 /dev/dri/card0
b2ea9000-b34e9000 rwxs cd000000 00:0d 17249 /dev/dri/card0
b34e9000-b3b29000 rwxs 28004000 00:0d 17249 /dev/dri/card0
b3b29000-b4169000 rwxs c0020000 00:0d 17249 /dev/dri/card0
b4169000-b43a5000 r-xp 00000000 07:00 513689 /usr/lib/dri/i915_dri.so
b43a5000-b43b4000 rwxp 0023c000 07:00 513689 /usr/lib/dri/i915_dri.so
b43b4000-b43bf000 rwxp b43b4000 00:00 0
b43bf000-b449a000 r-xp 00000000 07:01 61251
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/libjogl.so
b449a000-b449b000 rwxp 000da000 07:01 61251
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/libjogl.so
b449b000-b44a3000 r-xp 00000000 07:00 234011 /usr/lib/libdrm.so.2.3.0
b44a3000-b44a4000 rwxp 00008000 07:00 234011 /usr/lib/libdrm.so.2.3.0
b44a4000-b44a8000 r-xp 00000000 07:00 234058 /usr/lib/libXxf86vm.so.1.0.0
b44a8000-b44a9000 rwxp 00003000 07:00 234058 /usr/lib/libXxf86vm.so.1.0.0
b44a9000-b4506000 r-xp 00000000 07:00 234110 /usr/lib/libGL.so.1.2
b4506000-b4508000 rwxp 0005d000 07:00 234110 /usr/lib/libGL.so.1.2
b4508000-b4509000 rwxp b4508000 00:00 0
b450e000-b4510000 rwxs e083b000 00:0d 17249 /dev/dri/card0
b4510000-b4511000 r-xp 00000000 07:01 61252
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/libjogl_awt.so
b4511000-b4512000 rwxp 00001000 07:01 61252
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/libjogl_awt.so
b4512000-b4513000 r-xp 00000000 07:00 482184
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjawt.so
b4513000-b4514000 rwxp 00000000 07:00 482184
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjawt.so
b4514000-b4515000 r-xp 00000000 07:01 61250
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/libgluegen-rt.so
b4515000-b4516000 rwxp 00000000 07:01 61250
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/libgluegen-rt.so
b4516000-b4576000 rwxs 00000000 00:08 21168158 /SYSV00000000 (deleted)
b4576000-b47f3000 rwxs 00000000 00:08 21135388 /SYSV00000000 (deleted)
b47f3000-b47f6000 ---p b47f3000 00:00 0
b47f6000-b4844000 rwxp b47f6000 00:00 0
b4844000-b4847000 ---p b4844000 00:00 0
b4847000-b4895000 rwxp b4847000 00:00 0
b4895000-b4897000 r-xp 00000000 07:00 282450
/usr/lib/pango/1.6.0/modules/pango-basic-fc.so
b4897000-b4898000 rwxp 00001000 07:00 282450
/usr/lib/pango/1.6.0/modules/pango-basic-fc.so
b4898000-b4915000 r-xp 00000000 07:00 264367
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf
b4915000-b491c000 r-xp 00000000 07:00 482166
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnio.so
b491c000-b491d000 rwxp 00006000 07:00 482166
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnio.so
b491d000-b4930000 r-xp 00000000 07:00 482165
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnet.so
b4930000-b4931000 rwxp 00013000 07:00 482165
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnet.so
b4931000-b4937000 r-xs 00000000 07:00 542061
/var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-x86.cache-2
b4937000-b4938000 r-xs 00000000 07:00 543336
/var/cache/fontconfig/fd9505950c048a77dc4b710eb6a628ed-x86.cache-2
b4938000-b493b000 r-xs 00000000 07:00 543335
/var/cache/fontconfig/ddc79d3ea06a7c6ffa86ede85f3bb5df-x86.cache-2
b493b000-b493c000 r-xs 00000000 07:00 543334
/var/cache/fontconfig/e7071f4a29fa870f4323321c154eba04-x86.cache-2
b493c000-b493d000 r-xs 00000000 07:00 543333
/var/cache/fontconfig/a2ab74764b07279e7c36ddb1d302cf26-x86.cache-2
b493d000-b4941000 r-xs 00000000 07:00 542055
/var/cache/fontconfig/921a30a17f0be15c70ac14043cb7a739-x86.cache-2
b4941000-b4942000 r-xs 00000000 07:00 543331
/var/cache/fontconfig/4c73fe0c47614734b17d736dbde7580a-x86.cache-2
b4942000-b4944000 r-xs 00000000 07:00 543330
/var/cache/fontconfig/646addb8444faa74ee138aa00ab0b6a0-x86.cache-2
b4944000-b4946000 r-xs 00000000 07:00 543329
/var/cache/fontconfig/20bd79ad97094406f7d1b9654bfbd926-x86.cache-2
b4946000-b4947000 r-xs 00000000 07:00 543328
/var/cache/fontconfig/75a2cd575a62c63e802c11411fb87c37-x86.cache-2
b4947000-b4949000 r-xs 00000000 07:00 543327
/var/cache/fontconfig/9c0624108b9a2ae8552f664125be8356-x86.cache-2
b4949000-b494f000 r-xs 00000000 07:00 543326
/var/cache/fontconfig/6d41288fd70b0be22e8c3a91e032eec0-x86.cache-2
b494f000-b4951000 r-xs 00000000 07:00 543325
/var/cache/fontconfig/de156ccd2eddbdc19d37a45b8b2aac9c-x86.cache-2
b4951000-b4953000 r-xs 00000000 07:00 542898
/var/cache/fontconfig/da1bd5ca8443ffe22927a23ce431d198-x86.cache-2
b4953000-b495b000 r-xs 00000000 07:00 542897
/var/cache/fontconfig/e3de0de479f42330eadf588a55fb5bf4-x86.cache-2
b495b000-b4961000 r-xs 00000000 07:00 542834
/var/cache/fontconfig/0f34bcd4b6ee430af32735b75db7f02b-x86.cache-2
b4961000-b4962000 r-xs 00000000 07:00 542833
/var/cache/fontconfig/4794a0821666d79190d59a36cb4f44b5-x86.cache-2
b4962000-b4964000 r-xs 00000000 07:00 542832
/var/cache/fontconfig/de9486f0b47a4d768a594cb4198cb1c6-x86.cache-2
b4964000-b496a000 r-xs 00000000 07:00 542831
/var/cache/fontconfig/d52a8644073d54c13679302ca1180695-x86.cache-2
b496a000-b496d000 r-xs 00000000 07:00 542830
/var/cache/fontconfig/6386b86020ecc1ef9690bb720a13964f-x86.cache-2
b496d000-b4971000 r-xs 00000000 07:00 542039
/var/cache/fontconfig/089dead882dea3570ffc31a9898cfb69-x86.cache-2
b4971000-b4973000 r-xs 00000000 07:00 542033
/var/cache/fontconfig/e13b20fdb08344e0e664864cc2ede53d-x86.cache-2
b4973000-b4974000 r-xs 00000000 07:00 543362
/var/cache/fontconfig/fcff1cd55d48a2c86a175e9943c3506d-x86.cache-2
b4974000-b4975000 r-xs 00000000 07:00 543361
/var/cache/fontconfig/e9e44584608a73233979f764b5f9dd81-x86.cache-2
b4975000-b4976000 r-xs 00000000 07:00 543360
/var/cache/fontconfig/b5a4f3f568a71026ccdc6a3a51afa9b4-x86.cache-2
b4976000-b4977000 r-xs 00000000 07:00 543359
/var/cache/fontconfig/2561679576a9c7fd2ce41d281d4e00d1-x86.cache-2
b4977000-b4978000 r-xs 00000000 07:00 543358
/var/cache/fontconfig/b8613a33de00eecd32d5a94c3c617829-x86.cache-2
b4978000-b497b000 r-xs 00000000 07:00 543357
/var/cache/fontconfig/b21a91cee725896328b8cee8091cf747-x86.cache-2
b497b000-b4980000 r-xs 00000000 07:00 543356
/var/cache/fontconfig/fd9416c4b92f07c6f59a3a8cf496e9dc-x86.cache-2
b4980000-b4982000 r-xs 00000000 07:00 543355
/var/cache/fontconfig/059138ec877db160474b4d5de1248d14-x86.cache-2
b4982000-b4983000 r-xs 00000000 07:00 543354
/var/cache/fontconfig/f5a93ac943883aa0fd9a7bfe0f6ec3c1-x86.cache-2
b4983000-b4985000 r-xs 00000000 07:00 543353
/var/cache/fontconfig/118d8d5311348bbdf5fe3b106d7c13d4-x86.cache-2
b4985000-b4986000 r-xs 00000000 07:00 543352
/var/cache/fontconfig/a1131b7be650f9abae4907495aa5815d-x86.cache-2
b4986000-b498b000 r-xs 00000000 07:00 543351
/var/cache/fontconfig/8ab5f685cd6d8ba67c37c908faf08172-x86.cache-2
b498b000-b498f000 r-xs 00000000 07:00 543350
/var/cache/fontconfig/0f32d3adc6a232110812e17374eaa446-x86.cache-2
b498f000-b4991000 r-xs 00000000 07:00 543349
/var/cache/fontconfig/7b4a97c10f6c0166998ddfa1cf7392fb-x86.cache-2
b4991000-b4994000 r-xs 00000000 07:00 543348
/var/cache/fontconfig/61c830dfac3fd78a12654da5e9ba3f56-x86.cache-2
b4994000-b4995000 r-xs 00000000 07:00 543347
/var/cache/fontconfig/e0f9e95429e756d56293ed4d63866094-x86.cache-2
b4995000-b4997000 r-xs 00000000 07:00 543346
/var/cache/fontconfig/4123634e9c08547d899d0aaff05ebe69-x86.cache-2
b4997000-b499b000 r-xs 00000000 07:00 543345
/var/cache/fontconfig/142ecfc435bad6f1fbc2648c1119d5eb-x86.cache-2
b499b000-b49a1000 r-xs 00000000 07:00 543344
/var/cache/fontconfig/102e5142c2e9e50c5e8ece26694a2dad-x86.cache-2
b49a1000-b49a2000 r-xs 00000000 07:00 543343
/var/cache/fontconfig/92a571655fb1c0ec1c4d6f496220600a-x86.cache-2
b49a2000-b49aa000 r-xs 00000000 07:00 543342
/var/cache/fontconfig/a960c40fc9306f090224a04585f8a963-x86.cache-2
b49aa000-b49ac000 r-xs 00000000 07:00 543341
/var/cache/fontconfig/9404ff413c67fc2a1526fd14eb4163a8-x86.cache-2
b49ac000-b49af000 r-xs 00000000 07:00 543340
/var/cache/fontconfig/b3fedf7c409f006ca1a6fceffceb77cf-x86.cache-2
b49af000-b49b1000 r-xs 00000000 07:00 542072
/var/cache/fontconfig/6330322105e0c4105d7c7a6ea2974107-x86.cache-2
b49b1000-b49c3000 r-xp 00000000 07:00 317075
/usr/lib/gtk-2.0/2.10.0/engines/libubuntulooks.so
b49c3000-b49c4000 rwxp 00011000 07:00 317075
/usr/lib/gtk-2.0/2.10.0/engines/libubuntulooks.so
b49c4000-b49c5000 r-xp 00000000 07:00 232335 /usr/lib/gconv/ISO8859-1.so
b49c5000-b49c7000 rwxp 00000000 07:00 232335 /usr/lib/gconv/ISO8859-1.so
b49c7000-b4a9e000 r-xp 00000000 07:00 263580
/usr/lib/locale/en_US.utf8/LC_COLLATE
b4a9e000-b4abc000 r-xp 00000000 07:00 233951 /usr/lib/libexpat.so.1.0.0
b4abc000-b4abe000 rwxp 0001d000 07:00 233951 /usr/lib/libexpat.so.1.0.0
b4abe000-b4ae0000 r-xp 00000000 07:00 233665 /usr/lib/libpng12.so.0.15.0
b4ae0000-b4ae1000 rwxp 00021000 07:00 233665 /usr/lib/libpng12.so.0.15.0
b4ae1000-b4af4000 r-xp 00000000 07:00 231781 /usr/lib/libz.so.1.2.3
b4af4000-b4af5000 rwxp 00012000 07:00 231781 /usr/lib/libz.so.1.2.3
b4af5000-b4b5d000 r-xp 00000000 07:00 233445 /usr/lib/libfreetype.so.6.3.10
b4b5d000-b4b60000 rwxp 00068000 07:00 233445 /usr/lib/libfreetype.so.6.3.10
b4b60000-b4b8a000 r-xp 00000000 07:00 234407
/usr/lib/libpangoft2-1.0.so.0.1600.2
b4b8a000-b4b8b000 rwxp 0002a000 07:00 234407
/usr/lib/libpangoft2-1.0.so.0.1600.2
b4b8b000-b4b90000 r-xp 00000000 07:00 234098 /usr/lib/libXrandr.so.2.1.0
b4b90000-b4b91000 rwxp 00005000 07:00 234098 /usr/lib/libXrandr.so.2.1.0
b4b91000-b4b93000 r-xp 00000000 07:00 234050 /usr/lib/libXinerama.so.1.0.0
b4b93000-b4b94000 rwxp 00001000 07:00 234050 /usr/lib/libXinerama.so.1.0.0
b4b94000-b4bb7000 r-xp 00000000 07:00 233999 /usr/lib/libfontconfig.so.1.2.0
b4bb7000-b4bbf000 rwxp 00023000 07:00 233999 /usr/lib/libfontconfig.so.1.2.0
b4bbf000-b4c2d000 r-xp 00000000 07:00 234388 /usr/lib/libcairo.so.2.11.1
b4c2d000-b4c2f000 rwxp 0006d000 07:00 234388 /usr/lib/libcairo.so.2.11.1
b4c2f000-b4cc3000 r-xp 00000000 07:00 234357 /usr/lib/libglib-2.0.so.0.1200.11
b4cc3000-b4cc4000 rwxp 00093000 07:00 234357 /usr/lib/libglib-2.0.so.0.1200.11
b4cc4000-b4cc6000 r-xp 00000000 07:00 234359
/usr/lib/libgmodule-2.0.so.0.1200.11
b4cc6000-b4cc7000 rwxp 00002000 07:00 234359
/usr/lib/libgmodule-2.0.so.0.1200.11
b4cc7000-b4d00000 r-xp 00000000 07:00 234358
/usr/lib/libgobject-2.0.so.0.1200.11
b4d00000-b4d01000 rwxp 00039000 07:00 234358
/usr/lib/libgobject-2.0.so.0.1200.11
b4d01000-b4d1a000 r-xp 00000000 07:00 234365 /usr/lib/libatk-1.0.so.0.1809.1
b4d1a000-b4d1c000 rwxp 00018000 07:00 234365 /usr/lib/libatk-1.0.so.0.1809.1
b4d1c000-b4d58000 r-xp 00000000 07:00 234405 /usr/lib/libpango-1.0.so.0.1600.2
b4d58000-b4d5a000 rwxp 0003b000 07:00 234405 /usr/lib/libpango-1.0.so.0.1600.2
b4d5a000-b4d61000 r-xp 00000000 07:00 234406
/usr/lib/libpangocairo-1.0.so.0.1600.2
b4d61000-b4d62000 rwxp 00007000 07:00 234406
/usr/lib/libpangocairo-1.0.so.0.1600.2
b4d62000-b4de5000 r-xp 00000000 07:00 234436
/usr/lib/libgdk-x11-2.0.so.0.1000.11
b4de5000-b4de8000 rwxp 00083000 07:00 234436
/usr/lib/libgdk-x11-2.0.so.0.1000.11
b4de8000-b4dfe000 r-xp 00000000 07:00 234435
/usr/lib/libgdk_pixbuf-2.0.so.0.1000.11
b4dfe000-b4dff000 rwxp 00015000 07:00 234435
/usr/lib/libgdk_pixbuf-2.0.so.0.1000.11
b4dff000-b5150000 r-xp 00000000 07:00 234437
/usr/lib/libgtk-x11-2.0.so.0.1000.11
b5150000-b5156000 rwxp 00351000 07:00 234437
/usr/lib/libgtk-x11-2.0.so.0.1000.11
b5156000-b5157000 rwxp b5156000 00:00 0
b5157000-b515a000 rwxp b5157000 00:00 0
b515a000-b51a8000 rwxp b515a000 00:00 0
b51a8000-b51ab000 ---p b51a8000 00:00 0
b51ab000-b51f9000 rwxp b51ab000 00:00 0
b51f9000-b51fc000 ---p b51f9000 00:00 0
b51fc000-b524a000 rwxp b51fc000 00:00 0
b524a000-b524d000 ---p b524a000 00:00 0
b524d000-b529b000 rwxp b524d000 00:00 0
b529b000-b5319000 r-xp 00000000 07:00 482178
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libfontmanager.so
b5319000-b5323000 rwxp 0007e000 07:00 482178
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libfontmanager.so
b5323000-b5328000 rwxp b5323000 00:00 0
b5328000-b5415000 r-xp 00000000 07:00 233943 /usr/lib/libX11.so.6.2.0
b5415000-b5419000 rwxp 000ed000 07:00 233943 /usr/lib/libX11.so.6.2.0
b5419000-b54df000 r-xp 00000000 07:00 482175
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libmlib_image.so
b54df000-b54e0000 rwxp 000c5000 07:00 482175
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libmlib_image.so
b54e0000-b555b000 r-xp 00000000 07:00 482176
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libawt.so
b555b000-b5562000 rwxp 0007b000 07:00 482176
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libawt.so
b5562000-b5586000 rwxp b5562000 00:00 0
b5586000-b5700000 r-xs 02c68000 07:00 482218
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/rt.jar
b5700000-b573b000 rwxp b5700000 00:00 0
b573b000-b5800000 ---p b573b000 00:00 0
b5800000-b5804000 r-xp 00000000 07:00 233949 /usr/lib/libXfixes.so.3.1.0
b5804000-b5805000 rwxp 00003000 07:00 233949 /usr/lib/libXfixes.so.3.1.0
b5805000-b580c000 r-xp 00000000 07:00 234001 /usr/lib/libXrender.so.1.3.0
b580c000-b580d000 rwxp 00006000 07:00 234001 /usr/lib/libXrender.so.1.3.0
b580d000-b5815000 r-xp 00000000 07:00 234176 /usr/lib/libXcursor.so.1.0.2
b5815000-b5816000 rwxp 00007000 07:00 234176 /usr/lib/libXcursor.so.1.0.2
b5816000-b581a000 r-xp 00000000 07:00 233941 /usr/lib/libXdmcp.so.6.0.0
b581a000-b581b000 rwxp 00003000 07:00 233941 /usr/lib/libXdmcp.so.6.0.0
b581b000-b581d000 r-xp 00000000 07:00 233939 /usr/lib/libXau.so.6.0.0
b581d000-b581e000 rwxp 00001000 07:00 233939 /usr/lib/libXau.so.6.0.0
b581e000-b5825000 r-xp 00000000 07:00 234037 /usr/lib/libXi.so.6.0.0
b5825000-b5826000 rwxp 00006000 07:00 234037 /usr/lib/libXi.so.6.0.0
b5826000-b582a000 r-xp 00000000 07:00 234052 /usr/lib/libXtst.so.6.1.0
b582a000-b582b000 rwxp 00003000 07:00 234052 /usr/lib/libXtst.so.6.1.0
b582b000-b5838000 r-xp 00000000 07:00 233945 /usr/lib/libXext.so.6.4.0
b5838000-b5839000 rwxp 0000d000 07:00 233945 /usr/lib/libXext.so.6.4.0
b5839000-b583b000 r-xs 00000000 07:00 542065
/var/cache/fontconfig/beeeeb3dfe132a8a0633a017c99ce0c0-x86.cache-2
b583b000-b583c000 r-xp 00000000 07:00 263578
/usr/lib/locale/en_US.utf8/LC_NUMERIC
b583c000-b583d000 r-xp 00000000 07:00 263579 /usr/lib/locale/en_US.utf8/LC_TIME
b583d000-b583e000 r-xp 00000000 07:00 263581
/usr/lib/locale/en_US.utf8/LC_MONETARY
b583e000-b583f000 r-xp 00000000 07:00 263583
/usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES
b583f000-b5840000 r-xp 00000000 07:00 263584 /usr/lib/locale/en_US.utf8/LC_PAPER
b5840000-b5841000 r-xp 00000000 07:00 263585 /usr/lib/locale/en_US.utf8/LC_NAME
b5841000-b5842000 r-xp 00000000 07:00 263586
/usr/lib/locale/en_US.utf8/LC_ADDRESS
b5842000-b5843000 r-xp 00000000 07:00 263587
/usr/lib/locale/en_US.utf8/LC_TELEPHONE
b5843000-b5844000 r-xp 00000000 07:00 263588
/usr/lib/locale/en_US.utf8/LC_MEASUREMENT
b5844000-b5882000 r-xp 00000000 07:00 495870
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
b5882000-b5885000 rwxp 0003d000 07:00 495870
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
b5885000-b58b5000 rwxp b5885000 00:00 0
b58b5000-b58bf000 r-xs 000fb000 07:01 61249
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/jogl.jar
b58bf000-b58c0000 ---p b58bf000 00:00 0
b58c0000-b5940000 rwxp b58c0000 00:00 0
b5940000-b5943000 ---p b5940000 00:00 0
b5943000-b5991000 rwxp b5943000 00:00 0
b5991000-b5994000 ---p b5991000 00:00 0
b5994000-b5a12000 rwxp b5994000 00:00 0
b5a12000-b5a15000 ---p b5a12000 00:00 0
b5a15000-b5a63000 rwxp b5a15000 00:00 0
b5a63000-b5a6a000 r-xs 00000000 07:00 231785 /usr/lib/gconv/gconv-modules.cache
b5a6a000-b5aa5000 r-xp 00000000 07:00 263577 /usr/lib/locale/en_US.utf8/LC_CTYPE
b5aa5000-b5aa8000 ---p b5aa5000 00:00 0
b5aa8000-b5af6000 rwxp b5aa8000 00:00 0
b5af6000-b5af9000 ---p b5af6000 00:00 0
b5af9000-b5b47000 rwxp b5af9000 00:00 0
b5b47000-b5b48000 ---p b5b47000 00:00 0
b5b48000-b5bdb000 rwxp b5b48000 00:00 0
b5bdb000-b5bf5000 rwxp b5bdb000 00:00 0
b5bf5000-b5bf8000 rwxp b5bf5000 00:00 0
b5bf8000-b5c13000 rwxp b5bf8000 00:00 0
b5c13000-b5c14000 rwxp b5c13000 00:00 0
b5c14000-b5c15000 rwxp b5c14000 00:00 0
b5c15000-b5c18000 rwxp b5c15000 00:00 0
b5c18000-b5c33000 rwxp b5c18000 00:00 0
b5c33000-b5c39000 rwxp b5c33000 00:00 0
b5c39000-b5c53000 rwxp b5c39000 00:00 0
b5c53000-b5c62000 rwxp b5c53000 00:00 0
b5c62000-b5cde000 rwxp b5c62000 00:00 0
b5cde000-b5dde000 rwxp b5cde000 00:00 0
b5dde000-b7cde000 rwxp b5dde000 00:00 0
b7cde000-b7ced000 r-xp 00000000 07:00 482161
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libzip.so
b7ced000-b7cef000 rwxp 0000e000 07:00 482161
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libzip.so
b7cef000-b7d12000 r-xp 00000000 07:00 482158
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjava.so
b7d12000-b7d14000 rwxp 00023000 07:00 482158
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjava.so
b7d14000-b7d1f000 r-xp 00000000 07:00 482157
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libverify.so
b7d1f000-b7d20000 rwxp 0000b000 07:00 482157
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libverify.so
b7d20000-b7d29000 r-xp 00000000 07:00 360610
/lib/tls/i686/cmov/libnss_files-2.5.so
b7d29000-b7d2b000 rwxp 00008000 07:00 360610
/lib/tls/i686/cmov/libnss_files-2.5.so
b7d2b000-b7d33000 r-xp 00000000 07:00 360613
/lib/tls/i686/cmov/libnss_nis-2.5.so
b7d33000-b7d35000 rwxp 00007000 07:00 360613
/lib/tls/i686/cmov/libnss_nis-2.5.so
b7d35000-b7d3c000 r-xp 00000000 07:00 360608
/lib/tls/i686/cmov/libnss_compat-2.5.so
b7d3c000-b7d3e000 rwxp 00006000 07:00 360608
/lib/tls/i686/cmov/libnss_compat-2.5.so
b7d3e000-b7d51000 r-xp 00000000 07:00 360607 /lib/tls/i686/cmov/libnsl-2.5.so
b7d51000-b7d53000 rwxp 00012000 07:00 360607 /lib/tls/i686/cmov/libnsl-2.5.so
b7d53000-b7d55000 rwxp b7d53000 00:00 0
b7d55000-b7d56000 r-xp 00000000 07:00 263589
/usr/lib/locale/en_US.utf8/LC_IDENTIFICATION
b7d56000-b7d58000 r-xs 0005e000 07:01 47390
/home/adam/javalibs/vecmath/vecmath/build/debug/lib/ext/vecmath.jar
b7d58000-b7d60000 rwxs 00000000 07:00 40737 /tmp/hsperfdata_adam/20461
b7d60000-b7d67000 r-xp 00000000 07:00 360621 /lib/tls/i686/cmov/librt-2.5.so
b7d67000-b7d69000 rwxp 00006000 07:00 360621 /lib/tls/i686/cmov/librt-2.5.so
b7d69000-b7d6c000 ---p b7d69000 00:00 0
b7d6c000-b7dba000 rwxp b7d6c000 00:00 0
b7dba000-b7ddf000 r-xp 00000000 07:00 360605 /lib/tls/i686/cmov/libm-2.5.so
b7ddf000-b7de1000 rwxp 00024000 07:00 360605 /lib/tls/i686/cmov/libm-2.5.so
b7de1000-b7de2000 rwxp b7de1000 00:00 0
b7de2000-b7f1d000 r-xp 00000000 07:00 360600 /lib/tls/i686/cmov/libc-2.5.so
b7f1d000-b7f1e000 r-xp 0013b000 07:00 360600 /lib/tls/i686/cmov/libc-2.5.so
b7f1e000-b7f20000 rwxp 0013c000 07:00 360600 /lib/tls/i686/cmov/libc-2.5.so
b7f20000-b7f23000 rwxp b7f20000 00:00 0
b7f23000-b7f25000 r-xp 00000000 07:00 360604 /lib/tls/i686/cmov/libdl-2.5.so
b7f25000-b7f27000 rwxp 00001000 07:00 360604 /lib/tls/i686/cmov/libdl-2.5.so
b7f27000-b7f2e000 r-xp 00000000 07:00 482160
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/jli/libjli.so
b7f2e000-b7f30000 rwxp 00006000 07:00 482160
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/jli/libjli.so
b7f30000-b7f31000 rwxp b7f30000 00:00 0
b7f31000-b7f44000 r-xp 00000000 07:00 360618
/lib/tls/i686/cmov/libpthread-2.5.so
b7f44000-b7f46000 rwxp 00013000 07:00 360618
/lib/tls/i686/cmov/libpthread-2.5.so
b7f46000-b7f48000 rwxp b7f46000 00:00 0
b7f48000-b7f4a000 r-xs 00003000 07:01 61248
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/gluegen-rt.jar
b7f4a000-b7f50000 r-xp 00000000 07:00 481576
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/native_threads/libhpi.so
b7f50000-b7f51000 rwxp 00006000 07:00 481576
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/native_threads/libhpi.so
b7f51000-b7f52000 rwxp b7f51000 00:00 0
b7f52000-b7f53000 r-xp b7f52000 00:00 0
b7f53000-b7f55000 rwxp b7f53000 00:00 0
b7f55000-b7f6e000 r-xp 00000000 07:00 360463 /lib/ld-2.5.so
b7f6e000-b7f70000 rwxp 00019000 07:00 360463 /lib/ld-2.5.so
bfaaf000-bfac4000 rwxp bfaaf000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]

VM Arguments:
java_command: org.davincisoft.DaVinci $

{application.args}

Launcher Type: SUN_STANDARD

Environment Variables:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
USERNAME=adam
LD_LIBRARY_PATH=/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client:/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386:/usr/lib/jvm/java-6-sun-1.6.0.00/jre/../lib/i386
SHELL=/bin/bash
DISPLAY=:0.0

Signal Handlers:
SIGSEGV: [libjvm.so+0x3aea90], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x3aea90], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x304e70], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x304e70], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x304e70], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x306e80], sa_mask[0]=0x00000004, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR2: [libjvm.so+0x306e80], sa_mask[0]=0x00000004, sa_flags=0x10000004

--------------- S Y S T E M ---------------

OS:4.0

uname:Linux 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686
libc:glibc 2.5 NPTL 2.5
rlimit: STACK 8192k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity
load average:2.09 1.47 1.32

CPU:total 1 family 6, cmov, cx8, fxsr, mmx, sse, sse2

Memory: 4k page, physical 507736k(5516k free), swap 488272k(394980k free)

vm_info: Java HotSpot(TM) Client VM (1.6.0-b105) for linux-x86, built on Nov 29
2006 01:24:38 by "java_re" with gcc 3.2.1-7a (J2SE release)
********************************************************************************



 Comments   
Comment by badapple [ 05/Aug/07 ]

To varify this you can down load Chris Campbell's Photo Cube example from his
blog at
(http://weblogs.java.net/blog/campbell/archive/2006/10/easy_2d3d_mixin.html),
which uses a GLJPanel.

Comment by kbr [ 06/Aug/07 ]

The two reported issues are likely different. The first does not use the Java 2D
/ OpenGL pipeline and is probably an application bug. The OpenGL state is
probably getting corrupted which is leading to GLX errors and ultimately
crashes. This can be diagnosed with the DebugGL.

The second may be a problem with the Java 2D / JOGL bridge and/or the Java 2D /
OpenGL pipeline, possibly driver-related. We are working with NVidia to address
regressions in the Java 2D / OpenGL pipeline caused by their most recent driver
release.

I would suggest you see if there is a more recent graphics driver available;
Intel's recent release of open-source Linux drivers for some of their integrated
chipsets may address some of these issues if applicable.

If you can provide a small and self-contained test case clearly illustrating a
bug in JOGL's OpenGL context management then please reopen this bug or file a
new one. Closing as "works for me".

Comment by badapple [ 07/Aug/07 ]

I am reopening this due to the fact that the last person did not test
thoroughly, and it shows up in your own demos, so I feel no need to supply a
test case. This shows up in the jogl-demos that use a GLJPanel and
demos.jgears.JGears crashes the JVM with the current release 1.1 and rc3 on
Ubuntu 7.04 with JDK6. These work fine on windows. Here is the crash log.
**********************************************************************************
#

  1. An unexpected error has been detected by Java Runtime Environment:
    #
  2. SIGSEGV (0xb) at pc=0xb54ef317, pid=12105, tid=2966633360
    #
  3. Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode, sharing)
  4. Problematic frame:
  5. C [libX11.so.6+0x32317] XQueryExtension+0x17
    #
  6. If you would like to submit a bug report, please visit:
  7. http://java.sun.com/webapps/bugreport/crash.jsp
    #

--------------- T H R E A D ---------------

Current thread (0x08393400): JavaThread "AWT-EventQueue-0" [_thread_in_native,
id=12190]

siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x000004d0

Registers:
EAX=0xb516e0ad, EBX=0xb55aab2c, ECX=0x082f5e08, EDX=0x00000000
ESP=0xb0d320e0, EBP=0xb0d32128, ESI=0x00000000, EDI=0x00000000
EIP=0xb54ef317, CR2=0x000004d0, EFLAGS=0x00010282

Top of Stack: (sp=0xb0d320e0)
0xb0d320e0: b5d536f0 084892e0 08393628 08393650
0xb0d320f0: b0d321a4 08393400 b0d32294 b0d3211c
0xb0d32100: 063057d8 b0d32274 b0d32150 b0d321a4
0xb0d32110: 08393400 00000000 00000000 b55aab2c
0xb0d32120: 00000000 00000000 b0d32168 b54e3c6b
0xb0d32130: 00000000 b516e0ad b0d32150 b0d32154
0xb0d32140: b0d32158 b7f8b120 08393400 b0d32168
0xb0d32150: b7eb660e b7f8b120 00000010 b55bb158

Instructions: (pc=0xb54ef317)
0xb54ef307: ec 3c 8b 7d 08 e8 36 51 fe ff 81 c3 1b b8 0b 00
0xb54ef317: 8b 87 d0 04 00 00 85 c0 74 05 89 3c 24 ff 10 8b

Stack: [0xb0ce3000,0xb0d34000), sp=0xb0d320e0, free space=316k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libX11.so.6+0x32317] XQueryExtension+0x17
C [libX11.so.6+0x26c6b] XInitExtension+0x3b
C [libXext.so.6+0xc433] XextAddDisplay+0x53
C [libGL.so.1+0x20704]
C [libGL.so.1+0x20f64] __glXInitialize+0x14
C [libGL.so.1+0x21f6f] __glXSetupForCommand+0x3f
C [libGL.so.1+0x2020b]
C [libjogl.so+0x48c60] Java_com_sun_opengl_impl_x11_GLX_glXDestroyContext__JJ+0x3e
j com.sun.opengl.impl.x11.GLX.glXDestroyContext(JJ)V+0
j com.sun.opengl.impl.x11.X11GLContext.destroyImpl()V+78
j com.sun.opengl.impl.GLContextImpl.destroy()V+60
j javax.media.opengl.GLJPanel.handleReshape()V+425
j javax.media.opengl.GLJPanel.paintComponent(Ljava/awt/Graphics;)V+27
j demos.jgears.JGears.paintComponent(Ljava/awt/Graphics;)V+2
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+269
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+301
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+301
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+301
j javax.swing.JLayeredPane.paint(Ljava/awt/Graphics;)V+73
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paintToOffscreen(Ljava/awt/Graphics;IIIIII)V+72
j
javax.swing.BufferStrategyPaintManager.paint(Ljavax/swing/JComponent;Ljavax/swing/JComponent;Ljava/awt/Graphics;IIII)Z+157
j
javax.swing.RepaintManager.paint(Ljavax/swing/JComponent;Ljavax/swing/JComponent;Ljava/awt/Graphics;IIII)V+52
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+204
j
java.awt.GraphicsCallback$PaintCallback.run(Ljava/awt/Component;Ljava/awt/Graphics;)V+2
j
sun.awt.SunGraphicsCallback.runOneComponent(Ljava/awt/Component;Ljava/awt/Rectangle;Ljava/awt/Graphics;Ljava/awt/Shape;I)V+155
j
sun.awt.SunGraphicsCallback.runComponents([Ljava/awt/Component;Ljava/awt/Graphics;I)V+104
j java.awt.Container.paint(Ljava/awt/Graphics;)V+62
j javax.swing.RepaintManager.paintDirtyRegions(Ljava/util/Map;)V+245
j javax.swing.RepaintManager.paintDirtyRegions()V+46
j com.sun.opengl.util.Animator$1.run()V+371
j java.awt.event.InvocationEvent.dispatch()V+11
j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+26
j java.awt.EventDispatchThread.pumpOneEventForFilters(I)Z+156
j
java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+30
j
java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j java.awt.EventDispatchThread.run()V+9
v ~StubRoutines::call_stub
V [libjvm.so+0x20967d]
V [libjvm.so+0x3057d8]
V [libjvm.so+0x208f90]
V [libjvm.so+0x20901d]
V [libjvm.so+0x279215]
V [libjvm.so+0x38035f]
V [libjvm.so+0x3066b3]
C [libpthread.so.0+0x531b]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.sun.opengl.impl.x11.GLX.glXDestroyContext(JJ)V+0
j com.sun.opengl.impl.x11.X11GLContext.destroyImpl()V+78
j com.sun.opengl.impl.GLContextImpl.destroy()V+60
j javax.media.opengl.GLJPanel.handleReshape()V+425
j javax.media.opengl.GLJPanel.paintComponent(Ljava/awt/Graphics;)V+27
j demos.jgears.JGears.paintComponent(Ljava/awt/Graphics;)V+2
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+269
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+301
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+301
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+301
j javax.swing.JLayeredPane.paint(Ljava/awt/Graphics;)V+73
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paintToOffscreen(Ljava/awt/Graphics;IIIIII)V+72
j
javax.swing.BufferStrategyPaintManager.paint(Ljavax/swing/JComponent;Ljavax/swing/JComponent;Ljava/awt/Graphics;IIII)Z+157
j
javax.swing.RepaintManager.paint(Ljavax/swing/JComponent;Ljavax/swing/JComponent;Ljava/awt/Graphics;IIII)V+52
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+204
j
java.awt.GraphicsCallback$PaintCallback.run(Ljava/awt/Component;Ljava/awt/Graphics;)V+2
j
sun.awt.SunGraphicsCallback.runOneComponent(Ljava/awt/Component;Ljava/awt/Rectangle;Ljava/awt/Graphics;Ljava/awt/Shape;I)V+155
j
sun.awt.SunGraphicsCallback.runComponents([Ljava/awt/Component;Ljava/awt/Graphics;I)V+104
j java.awt.Container.paint(Ljava/awt/Graphics;)V+62
j javax.swing.RepaintManager.paintDirtyRegions(Ljava/util/Map;)V+245
j javax.swing.RepaintManager.paintDirtyRegions()V+46
j com.sun.opengl.util.Animator$1.run()V+371
j java.awt.event.InvocationEvent.dispatch()V+11
j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+26
j java.awt.EventDispatchThread.pumpOneEventForFilters(I)Z+156
j
java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+30
j
java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j java.awt.EventDispatchThread.run()V+9
v ~StubRoutines::call_stub

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
=>0x08393400 JavaThread "AWT-EventQueue-0" [_thread_in_native, id=12190]
0x08058c00 JavaThread "DestroyJavaVM" [_thread_blocked, id=12112]
0x082f6000 JavaThread "Thread-2" [_thread_blocked, id=12172]
0x080d8000 JavaThread "AWT-Shutdown" [_thread_blocked, id=12164]
0x082e6400 JavaThread "AWT-XAWT" daemon [_thread_blocked, id=12149]
0x082bd400 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=12145]
0x0808dc00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=12126]
0x0808c400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=12125]
0x0808b000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=12124]
0x08082000 JavaThread "Finalizer" daemon [_thread_blocked, id=12123]
0x08081000 JavaThread "Reference Handler" daemon [_thread_blocked, id=12122]

Other Threads:
0x08077800 VMThread [id=12121]
0x0808f400 WatcherThread [id=12127]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
def new generation total 960K, used 124K [0x8c050000, 0x8c150000, 0x8c530000)
eden space 896K, 12% used [0x8c050000, 0x8c06b508, 0x8c130000)
from space 64K, 23% used [0x8c130000, 0x8c133d50, 0x8c140000)
to space 64K, 0% used [0x8c140000, 0x8c140000, 0x8c150000)
tenured generation total 4096K, used 948K [0x8c530000, 0x8c930000, 0x90050000)
the space 4096K, 23% used [0x8c530000, 0x8c61d3f8, 0x8c61d400, 0x8c930000)
compacting perm gen total 12288K, used 2676K [0x90050000, 0x90c50000, 0x94050000)
the space 12288K, 21% used [0x90050000, 0x902ed218, 0x902ed400, 0x90c50000)
ro space 8192K, 73% used [0x94050000, 0x9462e548, 0x9462e600, 0x94850000)
rw space 12288K, 57% used [0x94850000, 0x94f416c0, 0x94f41800, 0x95450000)

Dynamic libraries:
06000000-06412000 r-xp 00000000 07:00 400167
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/libjvm.so
06412000-0642b000 rwxp 00411000 07:00 400167
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/libjvm.so
0642b000-0684a000 rwxp 0642b000 00:00 0
08048000-08052000 r-xp 00000000 07:00 400141
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/bin/java
08052000-08053000 rwxp 00009000 07:00 400141
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/bin/java
08053000-08727000 rwxp 08053000 00:00 0 [heap]
8c050000-8c150000 rwxp 8c050000 00:00 0
8c150000-8c530000 rwxp 8c150000 00:00 0
8c530000-8c930000 rwxp 8c530000 00:00 0
8c930000-90050000 rwxp 8c930000 00:00 0
90050000-90c50000 rwxp 90050000 00:00 0
90c50000-94050000 rwxp 90c50000 00:00 0
94050000-9462f000 r-xs 00001000 07:00 400280
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
9462f000-94850000 rwxp 9462f000 00:00 0
94850000-94f42000 rwxp 005e0000 07:00 400280
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
94f42000-95450000 rwxp 94f42000 00:00 0
95450000-95529000 rwxp 00cd2000 07:00 400280
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
95529000-95850000 rwxp 95529000 00:00 0
95850000-95854000 r-xs 00dab000 07:00 400280
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
95854000-95c50000 rwxp 95854000 00:00 0
b0ce3000-b0ce6000 ---p b0ce3000 00:00 0
b0ce6000-b0d75000 rwxp b0ce6000 00:00 0
b0d75000-b34b5000 rwxs ca0c0000 00:0d 17246 /dev/dri/card0
b34b5000-b3af5000 rwxs cc800000 00:0d 17246 /dev/dri/card0
b3af5000-b4135000 rwxs cd000000 00:0d 17246 /dev/dri/card0
b4135000-b4775000 rwxs 28004000 00:0d 17246 /dev/dri/card0
b4775000-b4db5000 rwxs c0020000 00:0d 17246 /dev/dri/card0
b4db5000-b4dd3000 r-xp 00000000 07:00 102879 /usr/lib/libexpat.so.1.0.0
b4dd3000-b4dd5000 rwxp 0001d000 07:00 102879 /usr/lib/libexpat.so.1.0.0
b4ddf000-b501b000 r-xp 00000000 07:00 383563 /usr/lib/dri/i915_dri.so
b501b000-b502a000 rwxp 0023c000 07:00 383563 /usr/lib/dri/i915_dri.so
b502a000-b5035000 rwxp b502a000 00:00 0
b5035000-b5110000 r-xp 00000000 07:01 46555
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/libjogl.so
b5110000-b5111000 rwxp 000da000 07:01 46555
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/libjogl.so
b5111000-b5119000 r-xp 00000000 07:00 102939 /usr/lib/libdrm.so.2.3.0
b5119000-b511a000 rwxp 00008000 07:00 102939 /usr/lib/libdrm.so.2.3.0
b511a000-b511e000 r-xp 00000000 07:00 102986 /usr/lib/libXxf86vm.so.1.0.0
b511e000-b511f000 rwxp 00003000 07:00 102986 /usr/lib/libXxf86vm.so.1.0.0
b511f000-b517c000 r-xp 00000000 07:00 573744 /usr/lib/libGL.so.1.2
b517c000-b517e000 rwxp 0005d000 07:00 573744 /usr/lib/libGL.so.1.2
b517e000-b517f000 rwxp b517e000 00:00 0
b5182000-b5184000 rwxs e0843000 00:0d 17246 /dev/dri/card0
b5184000-b5186000 r-xp 00000000 07:01 46556
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/libjogl_awt.so
b5186000-b5187000 rwxp 00001000 07:01 46556
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/libjogl_awt.so
b5187000-b5188000 r-xp 00000000 07:00 400205
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjawt.so
b5188000-b5189000 rwxp 00000000 07:00 400205
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjawt.so
b5189000-b51d6000 rwxs 00000000 00:08 3801103 /SYSV00000000 (deleted)
b51d6000-b51d9000 ---p b51d6000 00:00 0
b51d9000-b5227000 rwxp b51d9000 00:00 0
b5227000-b522a000 rwxp b5227000 00:00 0
b522a000-b5278000 rwxp b522a000 00:00 0
b5278000-b528b000 r-xp 00000000 07:00 400180
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnet.so
b528b000-b528c000 rwxp 00013000 07:00 400180
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnet.so
b528c000-b528f000 ---p b528c000 00:00 0
b528f000-b52dd000 rwxp b528f000 00:00 0
b52dd000-b530b000 r-xp 00000000 07:00 400200
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjpeg.so
b530b000-b530c000 rwxp 0002e000 07:00 400200
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjpeg.so
b530c000-b5360000 r-xp 00000000 07:00 400201
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libcmm.so
b5360000-b5363000 rwxp 00054000 07:00 400201
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libcmm.so
b5363000-b5366000 ---p b5363000 00:00 0
b5366000-b53b4000 rwxp b5366000 00:00 0
b53b4000-b53b8000 r-xp 00000000 07:00 102877 /usr/lib/libXfixes.so.3.1.0
b53b8000-b53b9000 rwxp 00003000 07:00 102877 /usr/lib/libXfixes.so.3.1.0
b53b9000-b53c0000 r-xp 00000000 07:00 102929 /usr/lib/libXrender.so.1.3.0
b53c0000-b53c1000 rwxp 00006000 07:00 102929 /usr/lib/libXrender.so.1.3.0
b53c1000-b53c9000 r-xp 00000000 07:00 103104 /usr/lib/libXcursor.so.1.0.2
b53c9000-b53ca000 rwxp 00007000 07:00 103104 /usr/lib/libXcursor.so.1.0.2
b53ca000-b53cd000 ---p b53ca000 00:00 0
b53cd000-b541b000 rwxp b53cd000 00:00 0
b541b000-b5499000 r-xp 00000000 07:00 400199
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libfontmanager.so
b5499000-b54a3000 rwxp 0007e000 07:00 400199
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libfontmanager.so
b54a3000-b54a8000 rwxp b54a3000 00:00 0
b54a8000-b54ac000 r-xp 00000000 07:00 102869 /usr/lib/libXdmcp.so.6.0.0
b54ac000-b54ad000 rwxp 00003000 07:00 102869 /usr/lib/libXdmcp.so.6.0.0
b54ad000-b54af000 r-xp 00000000 07:00 102867 /usr/lib/libXau.so.6.0.0
b54af000-b54b0000 rwxp 00001000 07:00 102867 /usr/lib/libXau.so.6.0.0
b54b0000-b54b7000 r-xp 00000000 07:00 102965 /usr/lib/libXi.so.6.0.0
b54b7000-b54b8000 rwxp 00006000 07:00 102965 /usr/lib/libXi.so.6.0.0
b54b8000-b54bc000 r-xp 00000000 07:00 102980 /usr/lib/libXtst.so.6.1.0
b54bc000-b54bd000 rwxp 00003000 07:00 102980 /usr/lib/libXtst.so.6.1.0
b54bd000-b55aa000 r-xp 00000000 07:00 102871 /usr/lib/libX11.so.6.2.0
b55aa000-b55ae000 rwxp 000ed000 07:00 102871 /usr/lib/libX11.so.6.2.0
b55ae000-b55bb000 r-xp 00000000 07:00 102873 /usr/lib/libXext.so.6.4.0
b55bb000-b55bc000 rwxp 0000d000 07:00 102873 /usr/lib/libXext.so.6.4.0
b55bc000-b55bd000 r-xp 00000000 07:01 46554
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/libgluegen-rt.so
b55bd000-b55be000 rwxp 00000000 07:01 46554
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/libgluegen-rt.so
b55be000-b55c5000 r-xp 00000000 07:00 400181
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnio.so
b55c5000-b55c6000 rwxp 00006000 07:00 400181
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnio.so
b55c6000-b5604000 r-xp 00000000 07:00 400194
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
b5604000-b5607000 rwxp 0003d000 07:00 400194
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
b5607000-b56cd000 r-xp 00000000 07:00 400190
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libmlib_image.so
b56cd000-b56ce000 rwxp 000c5000 07:00 400190
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libmlib_image.so
b56ce000-b5749000 r-xp 00000000 07:00 400191
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libawt.so
b5749000-b5750000 rwxp 0007b000 07:00 400191
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libawt.so
b5750000-b57a4000 rwxp b5750000 00:00 0
b57a4000-b591e000 r-xs 02c68000 07:00 400245
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/rt.jar
b591e000-b5920000 r-xs 0000b000 07:01 62318
/home/adam/dev/java/jogl-demos/lib/joal.jar
b5920000-b592b000 r-xs 000fa000 07:01 46553
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/jogl.jar
b592b000-b592c000 ---p b592b000 00:00 0
b592c000-b59ac000 rwxp b592c000 00:00 0
b59ac000-b59af000 ---p b59ac000 00:00 0
b59af000-b59fd000 rwxp b59af000 00:00 0
b59fd000-b5a00000 ---p b59fd000 00:00 0
b5a00000-b5a7e000 rwxp b5a00000 00:00 0
b5a7e000-b5a81000 ---p b5a7e000 00:00 0
b5a81000-b5acf000 rwxp b5a81000 00:00 0
b5acf000-b5ad6000 r-xs 00000000 07:00 100713 /usr/lib/gconv/gconv-modules.cache
b5ad6000-b5b11000 r-xp 00000000 07:00 132620 /usr/lib/locale/en_US.utf8/LC_CTYPE
b5b11000-b5b14000 ---p b5b11000 00:00 0
b5b14000-b5b62000 rwxp b5b14000 00:00 0
b5b62000-b5b65000 ---p b5b62000 00:00 0
b5b65000-b5bb3000 rwxp b5b65000 00:00 0
b5bb3000-b5bb4000 ---p b5bb3000 00:00 0
b5bb4000-b5c47000 rwxp b5bb4000 00:00 0
b5c47000-b5c61000 rwxp b5c47000 00:00 0
b5c61000-b5c64000 rwxp b5c61000 00:00 0
b5c64000-b5c7f000 rwxp b5c64000 00:00 0
b5c7f000-b5c80000 rwxp b5c7f000 00:00 0
b5c80000-b5c81000 rwxp b5c80000 00:00 0
b5c81000-b5c84000 rwxp b5c81000 00:00 0
b5c84000-b5c9f000 rwxp b5c84000 00:00 0
b5c9f000-b5ca5000 rwxp b5c9f000 00:00 0
b5ca5000-b5cbf000 rwxp b5ca5000 00:00 0
b5cbf000-b5cce000 rwxp b5cbf000 00:00 0
b5cce000-b5d4a000 rwxp b5cce000 00:00 0
b5d4a000-b5e3a000 rwxp b5d4a000 00:00 0
b5e3a000-b7d4a000 rwxp b5e3a000 00:00 0
b7d4a000-b7d59000 r-xp 00000000 07:00 400176
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libzip.so
b7d59000-b7d5b000 rwxp 0000e000 07:00 400176
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libzip.so
b7d5b000-b7d7e000 r-xp 00000000 07:00 400173
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjava.so
b7d7e000-b7d80000 rwxp 00023000 07:00 400173
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjava.so
b7d80000-b7d8b000 r-xp 00000000 07:00 400172
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libverify.so
b7d8b000-b7d8c000 rwxp 0000b000 07:00 400172
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libverify.so
b7d8c000-b7d95000 r-xp 00000000 07:00 131234
/lib/tls/i686/cmov/libnss_files-2.5.so
b7d95000-b7d97000 rwxp 00008000 07:00 131234
/lib/tls/i686/cmov/libnss_files-2.5.so
b7d97000-b7d9f000 r-xp 00000000 07:00 131237
/lib/tls/i686/cmov/libnss_nis-2.5.so
b7d9f000-b7da1000 rwxp 00007000 07:00 131237
/lib/tls/i686/cmov/libnss_nis-2.5.so
b7da1000-b7da8000 r-xp 00000000 07:00 131232
/lib/tls/i686/cmov/libnss_compat-2.5.so
b7da8000-b7daa000 rwxp 00006000 07:00 131232
/lib/tls/i686/cmov/libnss_compat-2.5.so
b7daa000-b7dbd000 r-xp 00000000 07:00 131231 /lib/tls/i686/cmov/libnsl-2.5.so
b7dbd000-b7dbf000 rwxp 00012000 07:00 131231 /lib/tls/i686/cmov/libnsl-2.5.so
b7dbf000-b7dc1000 rwxp b7dbf000 00:00 0
b7dc1000-b7dc3000 r-xs 00003000 07:01 46552
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/gluegen-rt.jar
b7dc3000-b7dcb000 rwxs 00000000 07:00 606654 /tmp/hsperfdata_adam/12105
b7dcb000-b7dd2000 r-xp 00000000 07:00 131245 /lib/tls/i686/cmov/librt-2.5.so
b7dd2000-b7dd4000 rwxp 00006000 07:00 131245 /lib/tls/i686/cmov/librt-2.5.so
b7dd4000-b7dd7000 ---p b7dd4000 00:00 0
b7dd7000-b7e25000 rwxp b7dd7000 00:00 0
b7e25000-b7e4a000 r-xp 00000000 07:00 131229 /lib/tls/i686/cmov/libm-2.5.so
b7e4a000-b7e4c000 rwxp 00024000 07:00 131229 /lib/tls/i686/cmov/libm-2.5.so
b7e4c000-b7e4d000 rwxp b7e4c000 00:00 0
b7e4d000-b7f88000 r-xp 00000000 07:00 131224 /lib/tls/i686/cmov/libc-2.5.so
b7f88000-b7f89000 r-xp 0013b000 07:00 131224 /lib/tls/i686/cmov/libc-2.5.so
b7f89000-b7f8b000 rwxp 0013c000 07:00 131224 /lib/tls/i686/cmov/libc-2.5.so
b7f8b000-b7f8e000 rwxp b7f8b000 00:00 0
b7f8e000-b7f90000 r-xp 00000000 07:00 131228 /lib/tls/i686/cmov/libdl-2.5.so
b7f90000-b7f92000 rwxp 00001000 07:00 131228 /lib/tls/i686/cmov/libdl-2.5.so
b7f92000-b7f99000 r-xp 00000000 07:00 400175
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/jli/libjli.so
b7f99000-b7f9b000 rwxp 00006000 07:00 400175
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/jli/libjli.so
b7f9b000-b7f9c000 rwxp b7f9b000 00:00 0
b7f9c000-b7faf000 r-xp 00000000 07:00 131242
/lib/tls/i686/cmov/libpthread-2.5.so
b7faf000-b7fb1000 rwxp 00013000 07:00 131242
/lib/tls/i686/cmov/libpthread-2.5.so
b7fb1000-b7fb3000 rwxp b7fb1000 00:00 0
b7fb3000-b7fb4000 r-xs 00107000 07:01 62317
/home/adam/dev/java/jogl-demos/lib/joal-demos.jar
b7fb4000-b7fba000 r-xp 00000000 07:00 400161
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/native_threads/libhpi.so
b7fba000-b7fbb000 rwxp 00006000 07:00 400161
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/native_threads/libhpi.so
b7fbb000-b7fbc000 rwxp b7fbb000 00:00 0
b7fbc000-b7fbd000 r-xp b7fbc000 00:00 0
b7fbd000-b7fbf000 rwxp b7fbd000 00:00 0
b7fbf000-b7fd8000 r-xp 00000000 07:00 131087 /lib/ld-2.5.so
b7fd8000-b7fda000 rwxp 00019000 07:00 131087 /lib/ld-2.5.so
bfb93000-bfba8000 rwxp bfb93000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]

VM Arguments:
jvm_args: -Djava.library.path=/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/
java_command: demos.jgears.JGears
Launcher Type: SUN_STANDARD

Environment Variables:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
USERNAME=adam
LD_LIBRARY_PATH=/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client:/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386:/usr/lib/jvm/java-6-sun-1.6.0.00/jre/../lib/i386
SHELL=/bin/bash
DISPLAY=:0.0

Signal Handlers:
SIGSEGV: [libjvm.so+0x3aea90], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x3aea90], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x304e70], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x304e70], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x304e70], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x306e80], sa_mask[0]=0x00000004, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR2: [libjvm.so+0x306e80], sa_mask[0]=0x00000004, sa_flags=0x10000004

--------------- S Y S T E M ---------------

OS:4.0

uname:Linux 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686
libc:glibc 2.5 NPTL 2.5
rlimit: STACK 8192k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity
load average:2.36 1.19 0.86

CPU:total 1 family 6, cmov, cx8, fxsr, mmx, sse, sse2

Memory: 4k page, physical 507736k(6240k free), swap 488272k(394796k free)

vm_info: Java HotSpot(TM) Client VM (1.6.0-b105) for linux-x86, built on Nov 29
2006 01:24:38 by "java_re" with gcc 3.2.1-7a (J2SE release)

************************************************************************************





[JOGL-307] Rectangular (but still pow2) dds textures with mipmaps incorrectly loaded Created: 04/Jul/07  Updated: 06/Aug/07  Resolved: 06/Aug/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: davelloyd Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 307

 Description   

In the following from Texture.updateImage, the shorter of width or height will
become zero before all the mipmaps are loaded when the final mipmaps should be
(for example) 4x1, 2x1 and then 1x1:
for (int i = 0; i < mipmapData.length; i++) {
if (data.isDataCompressed())

{ // Need to use glCompressedTexImage2D directly to allocate and fill this image gl.glCompressedTexImage2D(texTarget, i, data.getInternalFormat(), width, height, data.getBorder(), mipmapData[i].remaining(), mipmapData[i]); }

else

{ // Allocate texture image at this level gl.glTexImage2D(texTarget, i, data.getInternalFormat(), width, height, data.getBorder(), data.getPixelFormat(), data.getPixelType(), null); updateSubImageImpl(data, texTarget, i, 0, 0, 0, 0, data.getWidth(), data.getHeight()); }

width /= 2;
height /= 2;
}

Suggest fix of:
width = Math.max (width/2, 1)

etc.

I believe there are other examples of this failure mode in Texture as well.



 Comments   
Comment by kbr [ 06/Aug/07 ]

Sorry for the delay in addressing this bug. A fix has been checked in; if it
doesn't work, please reopen the bug and attach an image which fails to load
properly. You should be able to test this with the demos.texture.TestTexture
test in the jogl-demos workspace.





[JOGL-310] Enhance TextureWriter to support decompression Created: 15/Jul/07  Updated: 15/Jul/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://www.javagaming.org/forums/index.php?topic=17079.0


Issuezilla Id: 310

 Description   

The TextureWriter SPI interface needs to be expanded in order to support
decompression of texture data. The interface needs to look something like

boolean matches(File file);
boolean readBackCompressed();
void write(File file, TextureData data) throws IOException;






[JOGL-309] Clarify GLPbuffer setSize() documentation and exception Created: 08/Jul/07  Updated: 08/Jul/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://www.javagaming.org/forums/index.php?topic=17005.0


Issuezilla Id: 309

 Description   

See above forum posting for suggestion on documentation and run-time exception
clarification.






[JOGL-308] Assymetry in null GLCapabilities parameter for off-screen context creation Created: 05/Jul/07  Updated: 05/Jul/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: moorej Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 308

 Description   

Passing a null for the GLCapabilities when creating a pbuffer throws a
NullPointerException. This is not the same for the onscreen drawables. After
looking at the source code, it appears that this is only a problem for Mac and
Windows, the X11 version checks for null.

Here's the stack trace

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at com.sun.opengl.impl.windows.WindowsGLDrawable.<init>(WindowsGLDrawabl
e.java:58)
at com.sun.opengl.impl.windows.WindowsPbufferGLDrawable.<init>(WindowsPb
ufferGLDrawable.java:62)
at com.sun.opengl.impl.windows.WindowsGLDrawableFactory$2.run(WindowsGLD
rawableFactory.java:147)
at com.sun.opengl.impl.windows.WindowsGLDrawableFactory.maybeDoSingleThr
eadedWorkaround(WindowsGLDrawableFactory.java:219)
at com.sun.opengl.impl.windows.WindowsGLDrawableFactory.createGLPbuffer(
WindowsGLDrawableFactory.java:164)
at SharedPBuffer.init(SharedPBuffer.java:87)
at com.sun.opengl.impl.GLDrawableHelper.init(GLDrawableHelper.java:72)
at javax.media.opengl.GLCanvas$InitAction.run(GLCanvas.java:307)
at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:1
89)
at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.
java:301)
at javax.media.opengl.GLCanvas.display(GLCanvas.java:133)
at javax.media.opengl.GLCanvas.paint(GLCanvas.java:166)
at sun.awt.RepaintArea.paintComponent(RepaintArea.java:248)
at sun.awt.RepaintArea.paint(RepaintArea.java:224)
at sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.java:293)
at java.awt.Component.dispatchEventImpl(Component.java:4483)
at java.awt.Component.dispatchEvent(Component.java:4237)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:600)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThre
ad.java:273)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.
java:183)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThre
ad.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)

at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
pBuffer = GLDrawableFactory.getFactory().createGLPbuffer(
null, null, 400, 400, canvas.getContext());

WindowsGLDrawable.java:58
this.capabilities = (GLCapabilities) capabilities.clone();

MacOSXGLDrawable.java:86
this.capabilities = (GLCapabilities) capabilities.clone();

  • whereas -
    X11GLDrawable.java:57
    this.capabilities = (capabilities == null) ? null :
    ((GLCapabilities) capabilities.clone());





[JOGL-306] Split JARs for JOGLAppletLauncher Created: 04/Jul/07  Updated: 04/Jul/07  Resolved: 04/Jul/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: corthbandt Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 306

 Description   

The JOGL jar has become quite big (1 MB). For a better user experience we'd
like to display sort of a splash screen and a custom progress bar.
But there's one JOGL component I can't delay-load: JOGLAppletLauncher. And
since it sits inside that big jogl.jar the browser has to fetch quite a lot
before my applet has a chance to run.
If the JOGLAppletLauncher was available (including it's JOGL dependencies of
course) as a separate, smaller JAR file I could have this init order:
fetch JOGLAppletLauncher.jar -> fetch MyApplet.jar -> [Init Splashscreen] ->
fetch MyRsc1.jar -> fetch MyRsc2.jar -> fetch jogl.jar... -> fetch
MyGameCode.jar -> [Run Game]

That way I'd have control over what gets loaded when and could display my
progress bar.

An alternative (and probably easier) approach would be to separate optional
JOGL components into an extra JAR. Looking at the contents and sizes of
jogl.jar my candidates would be:

  • Debug helpers (javax.media.opengl.TraceGL, javax.media.opengl.DebugGL)
  • Font data (com.sun.opengl.util.GLUTBitmap*)
  • CG stuff (com.sun.opengl.cg.*)
  • possibly com.sun.opengl.impl parts

This would reduce the initial download size quite a bit (~300 kB).

But really I'd prefer if only the stuff needed for startup was packaged
separately.

On a side note: AFAICS, JOGLAppletLauncher is supposed to load the DLLs/SOs in
parallel. My experiments at least indicate that those binary modules are still
loaded before my code gets any chance to run.



 Comments   
Comment by corthbandt [ 04/Jul/07 ]

Two points of clarification might be useful:
1st: The loading screen would be stock AWT of course, no OGL there
2nd: Yes I could package these JARs myself but I'd like to keep the benefit of
a widely trusted signing authority (Sun) instead of signing them myself.

Comment by kbr [ 04/Jul/07 ]

A new JNLPAppletLauncher has been released today which should address your
primary concern of initial download size. It is available at
http://applet-launcher.dev.java.net/ and a version of JOGL (1.1.1-rc3) was
released today which supports it. Please try it and post on the JOGL forum with
any feedback. We don't intend to split up jogl.jar, as DebugGL and TraceGL
actually do not add that much space above the base GL class. Also, the Pack200
compressed version of jogl.jar, which will be downloaded automatically if the
client is JDK 1.5 or above, is about 300K, or about 1/3 the size of the
uncompressed jogl.jar.





[JOGL-305] GLJPanel does not respect border insets. Created: 27/Jun/07  Updated: 27/Jun/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: mvsoder Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File GLJPanel.error.png    
Issuezilla Id: 305

 Description   

The GLJPanel does not take into account the insets allocated to painting borders.



 Comments   
Comment by mvsoder [ 27/Jun/07 ]

Created an attachment (id=103)
GLJPanel Border Problem





[JOGL-303] Add GL_BGRA code path to Screenshot Created: 29/May/07  Updated: 29/May/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://www.javagaming.org/forums/index.php?topic=16709.0


Issuezilla Id: 303

 Description   

It would be better to use a GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV pixel format
and type in conjunction with a TYPE_INT_ARGB BufferedImage in the Screenshot
class if OpenGL 1.2 is available. This is a more optimized code path through
most vendors' OpenGL drivers. See the above forum posting.






[JOGL-302] Black line on texture created with glu Created: 23/May/07  Updated: 23/May/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jouvieje Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File gluBuild2DMipmapsTEST.java     File PLATEOX2.bmp    
Issuezilla Id: 302

 Description   

A black line appear in top of the texture created with gluBuild2DMipmaps &
jogl.glu.nojava=false

This does not occures if the texture was created with :

  • gluBuild2DMipmaps & jogl.glu.nojava=true
  • glTexImage2D

This issue does not occure with all textures, a test case and its picture can be
found here :
http://jerome.jouvie.free.fr/downloads/gluBuild2DMipmapsTEST.java
http://jerome.jouvie.free.fr/downloads/PLATEOX2.bmp



 Comments   
Comment by jouvieje [ 23/May/07 ]

Created an attachment (id=101)
Test case

Comment by jouvieje [ 23/May/07 ]

Created an attachment (id=102)
Test case image





[JOGL-301] Add support for overlay planes Created: 14/May/07  Updated: 14/May/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: New Feature Priority: Major
Reporter: kenchapin Assignee: jogl-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 301

 Description   

Please add support for overlay planes. Overlay plane hardware is often found on
higher end video hardware such as nVidia's Quadro series of video cards.
Their availability can be queried through glXGetVisualConfigs and/or
glXGetFBConfigs request on X11 platforms and through the wglDescribeLayerPlane
API on Windows. I'm not sure about OSX.

Unfortunately this will require the addition of 8 bit rendering in jogl since
overlay planes are almost exclusively 8 bits deep.






[JOGL-300] Improvements to JOGL build process. Unbundling gluegen, etc Created: 08/May/07  Updated: 08/May/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: alistair64 Assignee: kbr
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File fix-solaris-compiler.patch     Text File uncouple-gluegen.patch    
Issuezilla Id: 300

 Description   

Currently the JOGL build process depends on the gluegen directory being available.

As part of the packaging of JOGL and JOAL for gentoo. I have started to separate
gluegen from the 2 packages build environment.

Basically the main patch just adds conditional checks so that if the properties
gluegen.jar and gluegen-rt.jar are avaliable files the gluegen build process is
skipped. Hopefully this will allow a compromise between your needs and those of
opensource projects wishing to package JOGL.

Secondly I noticed that you depend on an old version of cputasks. Newer
versions do not seem to support the suncc compiler and this patch just changes
those values to gcc. this patch might not be suitable for you.



 Comments   
Comment by alistair64 [ 08/May/07 ]

Created an attachment (id=99)
Main patch to uncouple gluegen from main build

Comment by alistair64 [ 08/May/07 ]

Created an attachment (id=100)
minor patch to fix building with newer versions of cputasks

Comment by alistair64 [ 08/May/07 ]

Also of note. While the main patch stops gluegen from being built when the jars
are already available. Files located within the gluegen directory are still
required. I propose that these should be duplicated within each make directory.

Also a requirement of separation will be gluegen having separate releases.





[JOGL-298] Flickering on Linux Created: 28/Apr/07  Updated: 28/Apr/07

Status: Open
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: kbr Assignee: jogl-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://www.javagaming.org/forums/index.php?topic=16573.0


Issuezilla Id: 298

 Description   

Apparently it isn't just on Windows that the AWT paints the background of
Canvases internally. See the above forum thread. We will need
-Dsun.awt.noerasebackground=true to be obeyed on X11 platforms and need the same
kind of per-canvas disableBackgroundErase() method implemented on the X11 side.






[JOGL-297] buffer size calculation for glTexImage2D is wrong Created: 25/Apr/07  Updated: 26/Apr/07  Resolved: 26/Apr/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kenchapin Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 297

 Description   

I'm getting a IndexOutOfBoundsException when the border size is > 0. Looking
at the generated GLImpl.java it seems that the necessary buffer size
calculation from the imageSizeInBytes() function is passed incorrect
arguments. From my reading of the OpenGL spec and looking at GLX client
libraries the border is inclusive of the the width and height, not exclusive.

glTexImage3D should have the same problem.



 Comments   
Comment by kbr [ 26/Apr/07 ]

Removed border from required buffer size computation as per bug report and
glTexImage1D, glTexImage2D, and glTexImage3D definitions.

Fix will be present in nightly builds dated 4/27 and later as well as the
forthcoming JOGL 1.1.1.





[JOGL-296] TextureIO cube map support broken Created: 20/Apr/07  Updated: 20/Apr/07  Resolved: 20/Apr/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun
URL: http://www.javagaming.org/forums/index.php?topic=16500.0


Issuezilla Id: 296

 Description   

During the recent rewrites to the TextureIO classes to support updating
sub-images and automatic mipmap generation, GL_TEXTURE_CUBE_MAP support was
broken. This is evidenced by the VertexProgRefract demo no longer working.



 Comments   
Comment by kbr [ 20/Apr/07 ]

Fixed code paths supporting cube maps. As a positive side-effect, the
VertexProgRefract demo's cube map is now rendered completely
correctly; inversion of the positive and negative Y images, and the
negative Y scale factor on the texture matrix, are no longer needed,
and the seams around the top image are gone. Fixed up spotlight
texture in HWShadowmapsSimple demo after removal of vertical flip in
BufferedImage loading in TextureIO.





[JOGL-226] JOGL seg faulting on Solaris AMD64 Created: 13/Jun/06  Updated: 20/Apr/07  Resolved: 20/Apr/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: gfxadmin Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: All


Issuezilla Id: 226

 Description   

When compiled on Solaris AMD64, JOGL often crashes with a seg fault on our
Solaris 10 AMD64 box. This is running with a fairly recent Nvidia framebuffer
and the latest and greatest Nvidia driver (it was crashing similarly with an
older Nvidia driver before upgrading).

The entire VM crashes almost immediately when a bad call is encountered. Other
programs run with no problems at all. It seems to happen immediately in the
native code dispatch call. Examples of problem programs include anything with a
PBuffer, shaders, or that calls glXSwapIntervalSGI (setSwapInterval()).

I have listed 3 typical stack traces below. To reproduce, just run example
programs that use any of these calls (most of them).

== Travis

Typical stack traces (this is what the VM leaves behind):

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.sun.opengl.impl.x11.GLXExtImpl.dispatch_glXSwapIntervalSGI0(IJ)I+0
j com.sun.opengl.impl.x11.GLXExtImpl.glXSwapIntervalSGI(I)I+30
j com.sun.opengl.impl.x11.X11GLContext.setSwapInterval(I)V+22
j com.sun.opengl.impl.GLImpl.setSwapInterval(I)V+5
j demos.gears.Gears.init(Ljavax/media/opengl/GLAutoDrawable;)V+40
j
com.sun.opengl.impl.GLDrawableHelper.init(Ljavax/media/opengl/GLAutoDrawable;)V+29
j javax.media.opengl.GLCanvas$InitAction.run()V+11
j
com.sun.opengl.impl.GLDrawableHelper.invokeGL(Ljavax/media/opengl/GLDrawable;Ljavax/media/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V+370
j
javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(Ljava/lang/Runnable;Ljava/lang/Runnable;)V+36
j javax.media.opengl.GLCanvas.display()V+9
j javax.media.opengl.GLCanvas.paint(Ljava/awt/Graphics;)V+1
j sun.awt.RepaintArea.paint(Ljava/lang/Object;Z)V+324
j sun.awt.motif.MComponentPeer.handleEvent(Ljava/awt/AWTEvent;)V+68
j java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+552
j java.awt.Component.dispatchEvent(Ljava/awt/AWTEvent;)V+2
j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+41
j java.awt.EventDispatchThread.pumpOneEventForHierarchy(ILjava/awt/Component;)Z+169
j
java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+26
j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j java.awt.EventDispatchThread.run()V+9
v ~StubRoutines::call_stub

Another:

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.sun.opengl.impl.x11.GLX.dispatch_glXChooseFBConfig1(JILjava/lang/Object;I

Ljava/lang/Object;IJ)[Ljava/nio/ByteBuffer;+0
j com.sun.opengl.impl.x11.GLX.glXChooseFBConfig(JI[II[II)[Lcom/sun/opengl/impl/

x11/GLXFBConfig;+151
j com.sun.opengl.impl.x11.X11PbufferGLDrawable.createPbuffer(J)V+90
j com.sun.opengl.impl.x11.X11PbufferGLDrawable.<init>(Ljavax/media/opengl/GLCap

abilities;II)V+163
j com.sun.opengl.impl.x11.X11GLDrawableFactory$3.run()V+16
j com.sun.opengl.impl.x11.X11GLDrawableFactory.maybeDoSingleThreadedWorkaround(

Ljava/lang/Runnable;)V+20
j com.sun.opengl.impl.x11.X11GLDrawableFactory.createGLPbuffer(Ljavax/media/ope

ngl/GLCapabilities;Ljavax/media/opengl/GLCapabilitiesChooser;IILjavax/media/open

gl/GLContext;)Ljavax/media/opengl/GLPbuffer;+47
j javax.media.opengl.GLJPanel.initialize()V+105
j javax.media.opengl.GLJPanel.paintComponent(Ljava/awt/Graphics;)V+8
j demos.jgears.JGears.paintComponent(Ljava/awt/Graphics;)V+2
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+257
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+523
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+289
j javax.swing.JComponent.paintWithOffscreenBuffer(Ljavax/swing/JComponent;Ljava

/awt/Graphics;IIIILjava/awt/Image;)V+165
j javax.swing.JComponent.paintDoubleBuffered(Ljavax/swing/JComponent;Ljava/awt/

Component;Ljava/awt/Graphics;IIII)Z+131
j javax.swing.JComponent._paintImmediately(IIII)V+711

And one last one:

Instructions: (pc=0xffffffffe05b6670)
0xffffffffe05b6660:
[error occurred during error reporting, step 100, id 0xb]

Stack: [0xfffffd7fdee00000,0xfffffd7fdeffe000), sp=0xfffffd7fdeffd2b8, free sp

ace=2036k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C 0xffffffffe05b6670

[error occurred during error reporting, step 120, id 0xb]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.sun.opengl.impl.GLImpl.dispatch_glGenProgramsARB1(ILjava/lang/Object;IJ)V

+0
j com.sun.opengl.impl.GLImpl.glGenProgramsARB(I[II)V+97
j demos.vertexProgRefract.VertexProgRefract.init(Ljavax/media/opengl/GLAutoDraw

able;)V+144
j com.sun.opengl.impl.GLDrawableHelper.init(Ljavax/media/opengl/GLAutoDrawable;

)V+29
j javax.media.opengl.GLCanvas$InitAction.run()V+11
j com.sun.opengl.impl.GLDrawableHelper.invokeGL(Ljavax/media/opengl/GLDrawable;

Ljavax/media/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V+370
j javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(Ljava/lang/Runnab

le;Ljava/lang/Runnable;)V+36
j javax.media.opengl.GLCanvas.display()V+9
j javax.media.opengl.GLCanvas.paint(Ljava/awt/Graphics;)V+1
j sun.awt.RepaintArea.paint(Ljava/lang/Object;Z)V+324
j sun.awt.motif.MComponentPeer.handleEvent(Ljava/awt/AWTEvent;)V+68



 Comments   
Comment by kbr [ 20/Apr/07 ]

The implementation of glXGetProcAddressARB on Solaris/AMD64 had a
similar problem to that seen on Linux/AMD64 distributions: internally
the return value is being cast to a 32-bit value and then
sign-extended back to 64 bits, causing the high half of its function
pointer return values to be lost. Worked around by using dlsym() for
lookup on this OS as well as on Linux/AMD64.

Fix will be present in the JOGL 1.1.0 final release.

Comment by kbr [ 20/Apr/07 ]

The above evaluation is incorrect. It turns out that the autogenerated GLX_JNI.c
was not receiving a prototype for glXGetProcAddressARB and so was receiving the
implicit one returning an int, which is obviously wrong on 64-bit architectures.
Re-fixed this bug by providing a prototype; removed the workaround in
X11GLDrawableFactory.





[JOGL-295] glCapabilities2AttribList() doesn't pair GLX_STEREO correctly Created: 19/Apr/07  Updated: 19/Apr/07  Resolved: 19/Apr/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: rugrat Assignee: kbr
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 295

 Description   

In classes/com/sun/opengl/impl/x11/X11GLDrawableFactory.java::
glCapabilities2AttribList() around line 370:

if (caps.getStereo())

{ res[idx++] = GLX.GLX_STEREO; }

According to the glXChooseFBConfig() man page, GLX_STEREO
must be followed by a boolean. If stereo is enabled, the
attribute list will get corrupted.



 Comments   
Comment by kbr [ 19/Apr/07 ]

I'm not sure which version of JOGL you're looking at but as far as I can tell
this was fixed even before the 1.0.0 release of JSR-231.

Note that the current logic is a little tricky, because the output of
glCapabilities2AttribList is used both by glXChooseVisual (for on-screen OpenGL
drawables) and glXChooseFBConfig. These APIs treat the GLX_STEREO and
GLX_DOUBLEBUFFER flags differently.

      • This issue has been marked as a duplicate of 242 ***




[JOGL-242] Unable to select single-buffered visual Created: 14/Aug/06  Updated: 19/Apr/07  Resolved: 19/Apr/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kcr Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 242

 Description   

There is a bug in the X11GLDrawableFactory.glCapabilities2AttribList method that
prevents an app from selecting a single-buffered visual on X11 platforms. That
method treats GLX_DOUBLEBUFFER as if it were an attribute that takes a boolean
parameter, which is incorrect for glXChooseVisual. The GLX_DOUBLEBUFFER
attribute takes no parameter, rather its presence indicates that a double
buffered visual should be selected. This bug causes two problems. First, if a
single-buffered visual is requested, the request will not be honored. Second,
the "false" value will be interpreted as "None" causing all subsequent
attributes to be ignored.



 Comments   
Comment by kcr [ 14/Aug/06 ]

Btw, you need to be careful when fixing this bug if the output of this method is
ever used by glXFBConfig, which does treat GLX_DOUBLEBUFFER as a boolean
attribute that takes a parameter.

Comment by kcr [ 14/Aug/06 ]

One more thing. The GLX_STEREO attribute is being set correctly for
glXChooseVisual and, as such, is currently incorrect when used by glXFBConfig.
In other words, it has the opposite problem of GLX_DOUBLEBUFFER.

Comment by kbr [ 14/Aug/06 ]

Fixed GLX_DOUBLEBUFFER and GLX_STEREO specifications for both
on-screen and pbuffer visuals as per suggestion.

Comment by kbr [ 19/Apr/07 ]
      • Issue 295 has been marked as a duplicate of this issue. ***




[JOGL-292] gluScaleImage does not scale correctly Created: 12/Apr/07  Updated: 19/Apr/07  Resolved: 19/Apr/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: alang Assignee: jogl-issues
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File JOGLTexture.java     JPEG File non-squareimage.jpg    
Issuezilla Id: 292

 Description   

Attached is an example application showing that gluScaleImage does not always
scale correctly.

Run the application with and without the following JVM command line argument:

-Djogl.glu.nojava

When the application is ran with this command line argument the texture is
displayed correctly. When the application is ran without the texture is not
scaled correctly.

--------------------------------------------
Attached application: JOGLTexture.java

import java.awt.*;
import java.awt.event.*;
import java.awt.image.*;
import java.io.*;
import java.nio.*;
import java.util.*;

import javax.imageio.*;
import javax.media.opengl.*;
import javax.media.opengl.glu.*;

/**

  • Example JOGL application showing bug when using gluScaleImage. The
    application
  • simply displays a quad with a texture map. Load any non square image, the
  • sample included is 134x57. Run the application with and without the following
  • JVM command line argument:
  • -Djogl.glu.nojava
  • When the application is ran with this command line argument the texture is
  • displayed correctly. When the application is ran without the texture is not
  • scaled correctly.
  • Run environment:
  • Machine : Dell Precision M70 laptop
  • OS : Windows XP SP2
  • Graphics : NVIDIA Quadro FX Go1400
  • Drivers : lastest from DELL dated: 22/03/2006 ver. 8.4.3.0
  • JVM : j2sdk1.4.2_10
  • JOGL : release 1.1.0-rc3 from Feb 14 2007
  • @author Alan Michael Gay, AVS Inc.
    */
    public class JOGLTexture extends Frame implements GLEventListener, ImageConsumer
    {
    // Name of example mage file to load
    String nonSquareImageFileName = ".
    non-squareimage.jpg";

//
// OpenGL variables.
//
private GLU glu = new GLU();
private int textureName;

//
// Workspace variables for consuming image.
//
boolean imageComplete = false;
private int imageWidth = 0;
private int imageHeight = 0;
private byte[] imageBuffer = null;

public JOGLTexture()
{
// Loads the image we are going to use in this example.
loadImage(nonSquareImageFileName);

// Specify the Frame window title and initial size.
setTitle("gluScaleImage bug");

// Create a listener object that will cause the application
// to exit when the user dismisses the Frame window.
this.addWindowListener(new WindowAdapter()
{
public void windowClosing(WindowEvent e)

{ System.exit(0); }

});

// Use the default capabilities.
GLCapabilities capabilities = new GLCapabilities();

GLCanvas canvas = new GLCanvas(capabilities);
canvas.addGLEventListener(this);

this.add(canvas);
}

/**

  • Loads the specified image from file.
  • @param fileName The string filename for the image.
    */
    private void loadImage(String fileName)
    {
    File input = new File(fileName);
    Image image = null;
    try { image = ImageIO.read(input); }

    catch (Throwable e)

    { System.out.println("Failed to load image file: " + e.getMessage()); }

ImageProducer imageSource = image.getSource();
imageSource.startProduction(this);
}

/**

  • Gets a new width and height based on a power of 2.
  • @param width The original image width
  • @param height The original image height
  • @return An in array with two values. The zeroth element containing the
    new width and the first
  • element the new height.
    */
    private int[] newImageSize(int width, int height)
    {
    int nN=1;
    while((width >> nN)>0) { nN++; }
    width = (width == (1<<(nN-1))) ? width : (1<<nN);

    nN = 1;
    while((height >> nN)>0) { nN++; }

height = (height == (1<<(nN-1))) ? height : (1<<nN);

int[] newDims = new int[2];
newDims[0] = width;
newDims[1] = height;

return newDims;
}

/**

  • Gets a new texture name
  • @param gl The gl context to get the name from.
  • @return An int value containing the texture name.
    */
    private int getTextureName(GL gl) { int[] result = new int[1]; gl.glGenTextures(1, result, 0); return result[0]; }

/**

  • Loads an image into opengl to be used as a texture.
  • @param gl The gl context into which to load the texture
  • @param width The width of the image.
  • @param height The height of the image.
  • @param texture The image.
    */
    private int loadTexture(GL gl , int width, int height, byte []texture) { int nComp = 4; int nAlign = 4; int textureName = getTextureName(gl); int[] newDims = newImageSize(width, height); int[] nOldAlign = new int[1]; gl.glGetIntegerv(GL.GL_UNPACK_ALIGNMENT, nOldAlign,0); gl.glPixelStorei(GL.GL_UNPACK_ALIGNMENT, nAlign); gl.glBindTexture(GL.GL_TEXTURE_2D, textureName); gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_WRAP_S, GL.GL_REPEAT); gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MAG_FILTER, GL.GL_LINEAR); gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MIN_FILTER, GL.GL_LINEAR); gl.glTexEnvi(GL.GL_TEXTURE_ENV, GL.GL_TEXTURE_ENV_MODE, GL.GL_MODULATE); gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_WRAP_T, GL.GL_REPEAT); int nSize = nComp*(int) newDims[0] * newDims[1]; byte[] newTexture = new byte [nSize]; ByteBuffer bufferIn = ByteBuffer.wrap(texture); ByteBuffer bufferOut = ByteBuffer.wrap(newTexture); glu.gluScaleImage(GL.GL_RGBA, width, height, GL.GL_UNSIGNED_BYTE, bufferIn, newDims[0], newDims[1], GL.GL_UNSIGNED_BYTE, bufferOut); gl.glBindTexture(GL.GL_TEXTURE_2D, textureName); ByteBuffer pixelBuffer = ByteBuffer.wrap(newTexture); gl.glTexImage2D(GL.GL_TEXTURE_2D, 0, nComp, newDims[0], newDims[1], 0, GL.GL_RGBA, GL.GL_UNSIGNED_BYTE, pixelBuffer); gl.glPixelStorei(GL.GL_UNPACK_ALIGNMENT, nOldAlign[0]); return textureName; }

/**

  • Implementation of GLEventListener.display
  • Draws a simple textured quad.
    */
    public void display(GLAutoDrawable arg0) { GL gl = arg0.getGL(); Color col = Color.white; float red = col.getRed()/255.0f; float green = col.getGreen()/255.0f; float blue = col.getBlue()/255.0f; gl.glColor3f(red, green, blue); gl.glEnable(GL.GL_TEXTURE_2D); gl.glBindTexture(GL.GL_TEXTURE_2D, textureName); gl.glBegin(GL.GL_QUADS); gl.glTexCoord2f(0.0f,1.0f); gl.glVertex3f(-1.0f, 1.0f, 0.0f); gl.glTexCoord2f(1.0f,1.0f); gl.glVertex3f(1.0f, 1.0f, 0.0f); gl.glTexCoord2f(1.0f,0.0f); gl.glVertex3f(1.0f, -1.0f, 0.0f); gl.glTexCoord2f(0.0f,0.0f); gl.glVertex3f(-1.0f, -1.0f, 0.0f); gl.glEnd(); }

public void init(GLAutoDrawable arg0)

{ GL gl = arg0.getGL(); if (imageComplete == false) throw new RuntimeException("Image has not been loaded"); // Load the texture to be used when displaying the textured quad. textureName = loadTexture(gl, imageWidth, imageHeight, imageBuffer); }

public void reshape(GLAutoDrawable arg0, int arg1, int arg2, int arg3, int
arg4)
{
}

public void displayChanged(GLAutoDrawable arg0, boolean arg1, boolean arg2)
{
}

//
// Implementation of ImageConsumer
//

public synchronized final void imageComplete(int status)

{ imageComplete = true; }

public synchronized final void setDimensions(int width, int height)

{ imageWidth = width; imageHeight = height; imageBuffer = new byte[4*width*height]; }

public synchronized final void setPixels(int x, int y, int w, int h,
ColorModel model,
int[] pixels, int off, int scansize)
{

if (w == 0 || h == 0)
return;

int srcRowIndex = off;
int dstRowIndex = ((imageHeight - 1) - y) * imageWidth + x;
for (int row = 0; row < h; row++) {
int srcIndex = srcRowIndex;
int dstIndex = dstRowIndex;
for (int col = 0; col < w; col++)

{ int pixel = pixels[srcIndex++]; int color = model.getRGB(pixel); imageBuffer[dstIndex*4 + 0] = (byte) (color & 0x000000ff); imageBuffer[dstIndex*4 + 1] = (byte)((color & 0x0000ff00) >> 8); imageBuffer[dstIndex*4 + 2] = (byte)((color & 0x00ff0000) >> 16); imageBuffer[dstIndex*4 + 3] = (byte) 0xff; dstIndex++; }

srcRowIndex += scansize;
dstRowIndex += imageWidth;
}
}

public synchronized final void setPixels(int x, int y, int w, int h,
ColorModel model,
byte[] pixels, int off, int scansize)

{ // ignore this version }

public synchronized final void setHints(int hintflags) {}
public synchronized final void setColorModel(ColorModel model) {}
public synchronized final void setProperties(Hashtable props) {}

/**

  • The main() method is called when the Java Virtual Machine starts up. It
  • just creates and displays an instance of the application.
    */
    public static void main(String args[]) { JOGLTexture app = new JOGLTexture(); app.pack(); app.setSize(300, 300); app.setVisible(true); }

    }



 Comments   
Comment by alang [ 12/Apr/07 ]

Created an attachment (id=97)
Example application showing issue

Comment by alang [ 12/Apr/07 ]

Created an attachment (id=98)
Example non sqaure image used by example application

Comment by alang [ 17/Apr/07 ]

none

Comment by kbr [ 18/Apr/07 ]

This is being investigated. It isn't necessary to adjust the priority.

If you would like to help figure out what is going on, you can compare the Java
sources for Mipmap.java, Image.java and ScaleImage.java to the relevant C GLU
sources in the OpenGL sample implementation and see if you can find the bug.
This is what we are doing internally.

Comment by kbr [ 18/Apr/07 ]

_

Comment by kbr [ 18/Apr/07 ]

Conversion scale factors for x and y dimensions were flipped. Also adjusted
Image.fill_image() so code does not assert.

Fix will be present in JOGL nightly builds dated 4/19 and later, and in the
forthcoming 1.1.0-rc4 and 1.1.0 final release.

Comment by alang [ 19/Apr/07 ]

Can confirm fix resolves issue for me. Thanks for such a prompt response.
Regards
Alan





[JOGL-291] native-taglet.properties with links changed to OpenGL SDK Created: 06/Apr/07  Updated: 19/Apr/07  Resolved: 19/Apr/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: eteq Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Archive File JOGLDocLinksGeneratorAndLibs.jar     Text File native-taglet.properties    
Issuezilla Id: 291

 Description   

The old links to the C functions in the javadocs linked to a page that was very
out-of-date and often down. The new OpenGL SDK has an excellent online "Blue
Book" (http://www.opengl.org/sdk/docs/man/), and the attached new
native-taglet.properties file will direct the C-function links to these pages.



 Comments   
Comment by eteq [ 06/Apr/07 ]

Created an attachment (id=95)
file to be included in make/ to have correct C-function links

Comment by eteq [ 06/Apr/07 ]

Created an attachment (id=96)
App used to generate native-taglet.properties

Comment by eteq [ 06/Apr/07 ]

Added the program used to generate the native-taglet.properties file. Makes
extensive use of the html parser at http://htmlparser.sourceforge.net/

Comment by kbr [ 06/Apr/07 ]

Thanks for this contribution. I've made you a Developer on the JOGL and GlueGen
projects; would you commit your changes? There's a zip archive of the earlier
native taglet link generator in make/lib/native-taglet-jogl.zip in the gluegen
workspace; if you could just replace that zip archive with your current one that
would be good.

Comment by kbr [ 19/Apr/07 ]

Checked in the program for generating the new native-taglet.properties into the
GlueGen source tree.





[JOGL-290] GLJPanel throws NullPointerExceptions with Java 2D/JOGL bridge Created: 23/Mar/07  Updated: 16/Apr/07  Resolved: 16/Apr/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kbr Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 290

 Description   

User GKW reports that:

> I found a couple minor bugs in GLJPanel. Calling getAutoSwapBufferMode and
> setAutoSwapBufferMode if you are using the j2d/opengl pipeline you will throw
> null pointer exceptions. Currently they both just check the
> hardwareAccelerationDisabled flag and don't check to see if oglPipelineEnabled
> is true.



 Comments   
Comment by kbr [ 16/Apr/07 ]

Fixed NPEs in setAutoSwapBufferMode and swapBuffers if Java 2D / JOGL
bridge is enabled. These methods are essentially no-ops on the
GLJPanel anyway because of how the copying to the Swing rendering area
(be it a BufferedImage or the Swing back buffer) is done.





[JOGL-288] Optionally create the TextRenderer's Texture with Mipmaps Created: 17/Mar/07  Updated: 16/Apr/07  Resolved: 16/Apr/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: emzic Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 288

 Description   

Hello,

it would be a nice feature if the TextRenderer could create it's Texture with
Mipmap information.

I suggest the the way of determining the mipmap-option similar to the way it is
handled in the TextureData's constructor. That is a boolean flag in the
constructor.

example:
TextRenderer(Font font, boolean antialiased, boolean useFractionalMetrics,
boolen mipmap)

thank you!



 Comments   
Comment by emzic [ 30/Mar/07 ]

i'd like to edit this issue:

since the TextRenderer relies on the TextureRenderer, it would be cool, if the
mipmap feature could be enabled on the TextureRenderer!

the image quality increases a lot when using mipmapped textures on objects in
the scene that are in the distance!

thanks!

Comment by kbr [ 16/Apr/07 ]

This functionality has been added along with support for automatic mipmap
generation using GL_GENERATE_MIPMAP in the TextureIO classes. The mipmapping
support is phrased as a request to both the TextureRenderer and the
TextRenderer; it will be enabled if the underlying OpenGL implementation
supports GL_GENERATE_MIPMAP.





[JOGL-274] GLException when GLJPanel (initially not visible) is made visible/showing Created: 21/Feb/07  Updated: 21/Mar/07  Resolved: 21/Mar/07

Status: Resolved
Project: jogl
Component/s: jogl
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: dmgaskin Assignee: jogl-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 274

 Description   

The following code demonstrates the problem

package de.gaskin.jogl.bugs;

import javax.media.opengl.GLJPanel;
import javax.swing.JFrame;
import javax.swing.JTabbedPane;
import javax.swing.JLabel;

class DMGJOGLBug1 extends JFrame {
DMGJOGLBug1(boolean produceBug) {
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JTabbedPane tp = new JTabbedPane();
GLJPanel threeD = new GLJPanel();
JLabel label = new JLabel("Now select the '3D' tab");
tp.setPreferredSize(new java.awt.Dimension(400, 400));
if (produceBug)

{ tp.add("2D", label); tp.add("3D", threeD); }

else

{ tp.add("3D", threeD); tp.add("2D", label); }

add(tp);
pack();
setVisible(true);
}
public static void main(String[] args)

{ boolean produceBug = true; if (args.length > 0) produceBug = false; new DMGJOGLBug1(produceBug); }

}



 Comments   
Comment by kbr [ 21/Feb/07 ]

I don't see any exception on my machine with NVidia graphics. What OS, graphics
card, and JDK version are you using? Did you properly specify
-Dsun.java2d.noddraw=true? Are you running the latest drivers from your vendor?
What is the stack trace of the exception thrown?

Comment by dmgaskin [ 21/Feb/07 ]

As you had no problems running my code I experimented a bit more with options
and properties.

The problem ONLY Occurs when invoked with "-Dsun.java2d.opengl=true"

The details follow.

Invoked:
========
java -Dsun.awt.noerasebackground=true -Dsun.java2d.noddraw=true
-Dsun.java2d.opengl=true de.gaskin.jogl.bugs.DMGJOGLBug1

OS:
==
Microsoft Windows XP [Version 5.1.2600]

JDK:
====
java version "1.6.0-rc"
Java(TM) SE Runtime Environment (build 1.6.0-rc-b104)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b104, mixed mode, sharing)

Graphics:
=========

INIT GL IS: com.sun.opengl.impl.GLImpl
Chosen GLCapabilities: GLCapabilities [DoubleBuffered: true, Stereo: false, Hard
wareAccelerated: true, DepthBits: 24, StencilBits: 0, Red: 8, Green: 8, Blue: 8,
Alpha: 0, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0,
Multisample: false ]
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce 6150 LE/PCI/SSE2/3DNOW!
GL_VERSION: 2.0.1

Exception Stack trace is:
=========================

exception in QueueFlusher:
javax.media.opengl.GLException: Unable to create OpenGL context for device
context 0x4f01139d
at
com.sun.opengl.impl.windows.WindowsGLContext.create(WindowsGLContext.java:122)
at
com.sun.opengl.impl.windows.WindowsGLContext.makeCurrentImpl(WindowsGLContext.java:150)
at com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:134)
at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:182)
at javax.media.opengl.GLJPanel$1.run(GLJPanel.java:596)
at
sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run(OGLRenderQueue.java:203)

JOGL Version is:
================
jogl-1.1.0-rc3-windows-i586

Please let me know if you need more information.

Regards
Dave

Comment by kbr [ 27/Feb/07 ]

This appears to be a driver-related bug. We are unlikely to have the resources
to investigate it further in the near future. A workaround is to specify
-Dsun.java2d.opengl.fbobject=false along with -Dsun.java2d.opengl=true . You
should probably report this bug to NVidia.

Comment by kbr [