[JOGL-246] Please install new JOGL webstart descriptors Created: 17/Sep/06  Updated: 17/Sep/06  Resolved: 17/Sep/06

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

Type: Improvement Priority: Blocker
Reporter: yottzumm 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: Mac OS X
Platform: Macintosh


Attachments: Text File orbit.jnlp     Java Source File Orbit2.java    
Issuezilla Id: 246

 Description   

Please install new JOGL web start jars on the jogl.dev.java.net webstart site
My application works from the command line, but not from web start. I tried
both the jogl.jnlp and the jogl-jsr-231.jnlp.

See: http://schizophrenics.net/yottzumm/chat3d/orbit.jnlp for stack traces.

This may not be a bug, but if the webstart jars aren't up to date, please think
about releasing a new version.

My webstart file looks like:
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0"
codebase="http://schizophrenics.net/yottzumm/chat3d"
href="chat3d.jnlp">
<information>
<title>Orbit</title>
<vendor>Schizophrenics.NET</vendor>
<homepage href="http://schizophrenics.net/yottzumm/chat3d"/>
<description>Orbit</description>
<description kind="short">Orbit</description>
<offline-allowed/>
</information>
<security>
<all-permissions/>
</security>
<resources>
<j2se href="http://java.sun.com/products/autodl/j2se" version="1.6+"/>
<jar href="lircom.jar" main="true"/>
<jar href="jogl-demos-util.jar"/>
<jar href="jogl-demos.jar"/>
<jar href="jogl-demos-data.jar"/>
<extension name="jogl-jsr-231"
href="https://jogl.dev.java.net/webstart/jogl-jsr-231.jnlp" />
<property name="sun.java2d.opengl" value="true"/>
</resources>
<application-desc main-class="lircom.Orbit2">
</application-desc>
</jnlp>
-----------------------------------
Code minus Animator is:
package lircom;

import java.awt.event.*;

import java.util.*;

import javax.swing.*;

import javax.media.opengl.*;

import demos.util.*;

import gleem.*;

import gleem.linalg.*;

/**

Wavelength-dependent refraction demo<br>

It's a chromatic aberration!<br>

sgreen@nvidia.com 4/2001<br><p>

Currently 3 passes - could do it in 1 with 4 texture units<p>

Ported to Java, Swing and ARB_fragment_program by Kenneth Russell

*/

public class Orbit2 extends GLJPanel implements WindowListener {

private boolean useRegisterCombiners;

private Animator animator;

private volatile boolean quit;

static public void main(String args[])

{ JFrame jf = new JFrame("JOGL Test Case"); Orbit2 canvas = new Orbit2(); jf.getContentPane().add(canvas); jf.setSize(800,500); jf.setVisible(true); jf.addWindowListener(canvas); }

public void windowActivated(java.awt.event.WindowEvent e) {}

public void windowClosed(java.awt.event.WindowEvent e) {}

public void windowClosing(java.awt.event.WindowEvent e)

{ System.exit(0); }

public void windowDeactivated(java.awt.event.WindowEvent e) {}

public void windowDeiconified(java.awt.event.WindowEvent e) {}

public void windowIconified(java.awt.event.WindowEvent e) {}

public void windowOpened(java.awt.event.WindowEvent e) {}

public Orbit2() {

super(new GLCapabilities(), null, null);

setSize(800, 500);

addGLEventListener(new Listener());

addMouseListener(new MouseAdapter() {

public void mouseClicked(MouseEvent e)

{ requestFocus(); }

});

animator = new Animator();

animator.add(this);

animator.start();

}

class Listener implements GLEventListener {

private boolean firstRender = true;

private int vtxProg;

private int fragProg;

private int cubemap;

private int bunnydl;

private int obj;

private ExaminerViewer viewer;

private Time time = new SystemTime();

private float animRate = (float) Math.toRadians(-6.0f); // Radians / sec

private float refract = 1.1f; // ratio of indicies of refraction

private float wavelengthDelta = 0.05f; // difference in refraction for each
"wavelength" (R,G,B)

private float fresnel = 2.0f; // Fresnel multiplier

private boolean wire = false;

private boolean toggleWire = false;

class coord

{ float x; float y; float z; }

;

int resolution = 100;

float e = 5;

float f = 5;

float g = 5;

float h = 5;

coord points[] = new coord[resolution*resolution];

coord oldpoints[] = new coord[resolution*resolution];

coord morphpoints[] = new coord[resolution*resolution];

coord facenormals[][] = new coord[resolution*resolution][6];

coord vertexnormals[] = new coord[resolution*resolution];

public void init(GLAutoDrawable drawable) {

GL gl = drawable.getGL();

// GLU glu = drawable.getGLU();

float cc = 0.0f;

gl.glClearColor(cc, cc, cc, 1);

gl.glColor3f(1,1,1);

gl.glEnable(GL.GL_DEPTH_TEST);

gl.glDisable(GL.GL_CULL_FACE);

if (firstRender) {

firstRender = false;

drawable.addKeyListener(new KeyAdapter() {

public void keyTyped(KeyEvent e)

{ dispatchKey(e.getKeyChar()); }

});

// Register the window with the ManipManager

ManipManager manager = ManipManager.getManipManager();

manager.registerWindow(drawable);

viewer = new ExaminerViewer(MouseButtonHelper.numMouseButtons());

viewer.setNoAltKeyMode(true);

viewer.attach(drawable, new BSphereProvider() {

public BSphere getBoundingSphere()

{ return new BSphere(new Vec3f(0, 0, 0), 50.0f); }

});

viewer.setVertFOV((float) (15.0f * Math.PI / 32.0f));

viewer.setZNear(-10.0f);

viewer.setZFar(10.0f);

}

gl.glShadeModel (GL.GL_SMOOTH);

gl.glMaterialfv(GL.GL_FRONT, GL.GL_SPECULAR, new float[]

{ 1.0f, 1.0f, 1.0f, 1.0f }

, 0);

gl.glMaterialfv(GL.GL_FRONT, GL.GL_SHININESS, new float[]

{ 50.0f }

, 0);

gl.glLightfv(GL.GL_LIGHT0, GL.GL_POSITION, new float[]

{ -1.0f, -1.0f, 1.0f, 0.0f }

, 0);

gl.glEnable(GL.GL_LIGHTING);

gl.glEnable(GL.GL_LIGHT0);

int i;

int j;

for ( i = 0; i < resolution; i++) {

for ( j = 0; j < resolution; j++)

{ points[i*resolution+j] = new coord(); oldpoints[i*resolution+j] = new coord(); morphpoints[i*resolution+j] = new coord(); vertexnormals[i*resolution+j] = new coord(); facenormals[i*resolution+j] = new coord[6]; facenormals[i*resolution+j][0] = new coord(); facenormals[i*resolution+j][1] = new coord(); facenormals[i*resolution+j][2] = new coord(); facenormals[i*resolution+j][3] = new coord(); facenormals[i*resolution+j][4] = new coord(); facenormals[i*resolution+j][5] = new coord(); }

}

material(gl, GL.GL_FRONT, 0.0215f, 0.1745f, 0.0215f, 0.07568f, 0.61424f,
0.07568f, 0.633f, 0.727811f, 0.633f, 0.6f);

material(gl, GL.GL_BACK, 1.0f, 1.0f, 1.0f,

1.0f, 1.0f, 1.0f,

1.0f, 1.0f, 1.0f, 0.6f);

}

Random random = new Random();

void set_fraction() {

int choice = random.nextInt(4);

switch (choice)

{ case 0: e += random.nextInt(2) * 2 - 1; break; case 1: f += random.nextInt(2) * 2 - 1; break; case 2: g += random.nextInt(2) * 2 - 1; break; case 3: h += random.nextInt(2) * 2 - 1; break; }

if (e < -20)

{ e = -20; }

if (e > 20)

{ e = 20; }

if (f < -20)

{ f = -20; }

if (f > 20)

{ f = 20; }

if (g < 1)

{ g = 1; }

if (g > 12)

{ g = 5; }

if (h < 1)

{ h = 1; }

if (h > 12)

{ h = 5; }

}

void generateCoordinates() {

float theta = 0.0f;

float phi = 0.0f;

float delta = (2f * 3.141592653f) / (resolution-1);

int i;

int j;

set_fraction();

for ( i = 0; i < resolution; i++) {

for ( j = 0; j < resolution; j++)

{ float rho = e + f * (float)Math.cos(g * theta) * (float)Math.cos(h * phi); points[i*resolution+j].x = rho * (float)Math.cos(phi) * (float)Math.cos(theta); points[i*resolution+j].y = rho * (float)Math.cos(phi) * (float)Math.sin(theta); points[i*resolution+j].z = rho * (float)Math.sin(phi); theta += delta; }

phi += delta;

}

}

void material(GL gl, int frontback, float ambr, float ambg, float ambb,

float difr, float difg, float difb,

float specr, float specg, float specb, float shine)

{

gl.glMaterialfv(frontback, GL.GL_AMBIENT, new float[] { ambr, ambg, ambb, 1.0f
}, 0);

gl.glMaterialfv(frontback, GL.GL_DIFFUSE, new float[] { difr, difg, difb, 1.0f
}, 0);

gl.glMaterialfv(frontback, GL.GL_SPECULAR, new float[]

{specr, specg, specb, 1.0f }

, 0);

gl.glMaterialf(frontback, GL.GL_SHININESS, shine * 128.0f);

}

void averagenormals(coord normal,

coord normal1, coord normal2, coord normal3,

coord normal4, coord normal5, coord normal6)

{ normal.x = (normal1.x + normal2.x + normal3.x + normal4.x + normal5.x + normal6.x) / 6; normal.y = (normal1.y + normal2.y + normal3.y + normal4.y + normal5.y + normal6.y) / 6; normal.z = (normal1.z + normal2.z + normal3.z + normal4.z + normal5.z + normal6.z) / 6; }

coord ab = new coord();

coord ac = new coord();

void compute_normal(coord normal, coord point0, coord point1, coord point2)

{ ab.x = point1.x - point0.x; ab.y = point1.y - point0.y; ab.z = point1.z - point0.z; ac.x = point2.x - point0.x; ac.y = point2.y - point0.y; ac.z = point2.z - point0.z; normal.x = ab.y * ac.z - ab.z * ac.y; normal.y = ab.z * ac.x - ab.x * ac.z; normal.z = ab.x * ac.y - ab.y * ac.x; }

void morph(int i, float m)

{ morphpoints[i].x = (points[i].x - oldpoints[i].x) * m + oldpoints[i].x; morphpoints[i].y = (points[i].y - oldpoints[i].y) * m + oldpoints[i].y; morphpoints[i].z = (points[i].z - oldpoints[i].z) * m + oldpoints[i].z; }

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

public void display(GLAutoDrawable drawable) {

GL gl = drawable.getGL();

// GLU glu = drawable.getGLU();

gl.glClear(GL.GL_COLOR_BUFFER_BIT|GL.GL_DEPTH_BUFFER_BIT);

viewer.update(gl);

ManipManager.getManipManager().updateCameraParameters(drawable,
viewer.getCameraParameters());

ManipManager.getManipManager().render(drawable, gl);

int i;

int j;

float m;

generateCoordinates();

for (m = 0; m < 1.0; m+=.0625)

{

gl.glClear (GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT);

// morph all the points

for ( i = 0; i < resolution; i++) {

for ( j = 0; j < resolution; j++)

{ morph(i*resolution+j, m); }

}

// compute face normals and vertex normals

for ( i = 0; i < resolution; i++) {

for ( j = 0; j < resolution; j++)

{ int i0 = i * resolution; int i0j = i0 + j; int ip1 = (i + 1) % resolution * resolution; int im1 = (i + resolution - 1) % resolution * resolution; int jp1 = (j + 1) % resolution; int jm1 = (j + resolution - 1) % resolution; compute_normal(facenormals[i0j][0], morphpoints[i0j], morphpoints[i0+jp1], morphpoints[ip1+j]); compute_normal(facenormals[i0j][1], morphpoints[i0j], morphpoints[ip1+j], morphpoints[ip1+jm1]); compute_normal(facenormals[i0j][2], morphpoints[i0j], morphpoints[ip1+jm1], morphpoints[i0+jm1]); compute_normal(facenormals[i0j][3], morphpoints[i0j], morphpoints[i0+jm1], morphpoints[im1+j]); compute_normal(facenormals[i0j][4], morphpoints[i0j], morphpoints[im1+j], morphpoints[im1+jp1]); compute_normal(facenormals[i0j][5], morphpoints[i0j], morphpoints[im1+jp1], morphpoints[i0+jp1]); averagenormals(vertexnormals[i0j], facenormals[i0j][0], facenormals[i0j][1], facenormals[i0j][2], facenormals[i0j][3], facenormals[i0j][4], facenormals[i0j][5]); }

}

for ( i = 0; i < resolution-1; i++) {

gl.glBegin(GL.GL_TRIANGLE_STRIP);

gl.glColor3f(1.0f, 1.0f, 0.5f);

for ( j = 0; j < resolution; j++)

{ coord point = morphpoints[i*resolution+j]; coord normal = vertexnormals[i*resolution+j]; gl.glNormal3f(normal.x, normal.y, normal.z); // gl.glNormal3f(point.x, point.y, point.z); gl.glVertex3f(point.x, point.y, point.z); point = morphpoints[(i+1)*resolution+j]; normal = vertexnormals[(i+1)*resolution+j]; gl.glNormal3f(normal.x, normal.y, normal.z); //gl.glNormal3f(point.x, point.y, point.z); gl.glVertex3f(point.x, point.y, point.z); }

gl.glEnd();

}

}

for ( i = 0; i < resolution; i++) {

for ( j = 0; j < resolution; j++)

{ int i0 = i * resolution; int i0j = i0 + j; oldpoints[i0j].x = points[i0j].x; oldpoints[i0j].y = points[i0j].y; oldpoints[i0j].z = points[i0j].z; }

}

}

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

{ GL gl = drawable.getGL(); gl.glViewport (x, y, width, height); gl.glMatrixMode (GL.GL_PROJECTION); gl.glLoadIdentity (); gl.glOrtho (-30.0, 30.0, -30.0, 30.0, 30.0, -30.0); gl.glMatrixMode (GL.GL_MODELVIEW); gl.glLoadIdentity (); }

private void dispatchKey(char k) {

}

}

}



 Comments   
Comment by yottzumm [ 17/Sep/06 ]

Created an attachment (id=86)
Main file, minus Animator (do an import).

Comment by yottzumm [ 17/Sep/06 ]

Created an attachment (id=87)
Java Web Start file

Comment by kbr [ 17/Sep/06 ]

The current JOGL extension JNLPs have moved; the one you're pointing to is
obsolete. Please see the JOGL User's Guide (linked from the JOGL home page) for
the current one:

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

The official 1.0.0 release of JSR-231 was just done this past week. There is a
permanently-archived extension JNLP for this release as well:

http://download.java.net/media/jogl/builds/archive/jsr-231-1.0.0/jogl.jnlp

See the following thread on javagaming.org for more information:

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

Please indicate whether this information solves your problem. I would like to
completely delete the jogl.jnlp and other files from the www/ subdirectory of
jogl.dev.java.net at this point.

Comment by kbr [ 17/Sep/06 ]

The submitter indicated using the up-to-date extension JNLP solved the problem.
Closing as "works for me".





[JOGL-216] Cannot create GLCanvas on non-default GraphicsDevice Created: 14/Apr/06  Updated: 30/May/06  Resolved: 30/May/06

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

Type: Bug Priority: Blocker
Reporter: jbwest 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: 216

 Description   

Multiheaded (NVIDIA) Linux system.

Create GLCanvas with cap=GLCapabilities [DoubleBuffered: true, Stereo: false,
HardwareAccelerated: true, DepthBits: 24, StencilBits: 0, Red: 12, Green: 12,
Blue: 12, Alpha: 12, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum:
0, Multisample: false ] graphicsDevice= X11GraphicsDevice[screen=1]

results in:
javax.media.opengl.GLException: Error while enumerating available XVisualInfos
at
com.sun.opengl.impl.x11.X11GLDrawableFactory.chooseGraphicsConfiguration(X11GLDrawableFactory.java:135)
at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:113)

Create on Screen 0 is ok, but, of course, the canvas cannot be added to a
container on screen 1.

Note that "java screen 1" isn't a "Screen 1" in X11 parlance; this is a single
big desktop using NVIDIA proprietary driver.



 Comments   
Comment by kbr [ 17/Apr/06 ]

I'll need to ask you to please help with this investigation as I don't have a
machine with this configuration to test on.

How are you getting the desktop to span the two displays? Could you please
attach your xorg.conf or similar? I assume there is one X server running for
both displays? Is this a single graphics card with dual outputs, or two graphics
cards?

Could you please check out and build the current source tree as per the
instructions on the JOGL home page? It is going to be necessary to instrument
some routines in X11GLDrawableFactory.java to see what is going wrong and to
figure out what should be happening. The last time I heard, which was a couple
of years ago, multihead support on X11 platforms was working correctly in JOGL.

It would probably be easiest to conduct this discussion over email, so please
feel free to email me.

Comment by jbwest [ 30/May/06 ]

Latest CVS (as of 5/29/2006) has resolved the issue with the addition of the
Xinerama-aware native code.

-jbw





[JOGL-195] Pbuffer support broken on X11 platforms Created: 24/Jan/06  Updated: 24/Jan/06  Resolved: 24/Jan/06

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

Type: Bug Priority: Blocker
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: 195

 Description   

Pbuffer support in JOGL seems to be broken on all X11 platforms. The JGears demo
shows either garbage or nothing for the OpenGL view. Something must have been
broken during the recent code refactoring to make pbuffers and on-screen
drawables share the same pixel format selection code path. This issue was
reported by Paul Butcher from Advanced System Architectures UK.



 Comments   
Comment by kbr [ 24/Jan/06 ]

It turns out that pbuffer support wasn't completely broken, but the
GLX_DOUBLEBUFFER bit wasn't being set properly for single-buffered windows and
pbuffers, which mattered in particular for the JGears demo (and the GLJPanel)
which read back the contents of the front buffer.





[JOGL-158] Endian issue Created: 29/Apr/05  Updated: 29/Apr/05  Resolved: 29/Apr/05

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

Type: Bug Priority: Blocker
Reporter: ataron 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: PC


Issuezilla Id: 158

 Description   

My platform: PC, Windows XP Home, latest jogl version (both dlls and jar)
The "gl.glSelectBuffer(BUFSIZE, selectBuf);" function returns results that are
in wrong endian order (I needed to swap the 4 bytes for each entry in selectBuf
in order to obtain the correct names).
This was not an issue with version 1.0 (April 12 2004).

Thank you,
Andrei



 Comments   
Comment by kbr [ 29/Apr/05 ]

The selectBuf's byte order is not being set to ByteOrder.nativeOrder(). This is
a bug in the application, not in JOGL. See the BufferUtils class in
net.java.games.jogl.util for convenience routines which allocate with the
correct byte order.





[JOGL-154] Patches for build problems Created: 02/Apr/05  Updated: 04/Apr/05  Resolved: 04/Apr/05

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

Type: Task Priority: Blocker
Reporter: gtgtgtgtgtgtgt 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 diffs.txt    
Issuezilla Id: 154

 Description   

These two minor fixes address the problems discussed here:
http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1108328385

The first part handles an invalid lvalue complaint from the stricter GCC 4
preview, and the second part fixes a bug in gluegen preventing jogl from
building reliably.

Index: src/net/java/games/gluegen/CMethodBindingEmitter.java
===================================================================
RCS file: /cvs/jogl/src/net/java/games/gluegen/CMethodBindingEmitter.java,v
retrieving revision 1.7
diff -u -r1.7 CMethodBindingEmitter.java
— src/net/java/games/gluegen/CMethodBindingEmitter.java 4 Oct 2004
22:55:38 -0000 1.7
+++ src/net/java/games/gluegen/CMethodBindingEmitter.java 2 Apr 2005
09:02:11 -0000
@@ -609,7 +609,7 @@
writer.print(" ");
emitGetStringUTFChars(writer,
"(jstring) _tmpObj",

  • "(const char*)"convName"_copy[_copyIndex]");
    + convName+"_copy[_copyIndex]");
    }
    else if (isNIOBufferClass(subArrayElementJavaType))
    {
    Index: src/net/java/games/gluegen/cgram/types/CompoundType.java
    ===================================================================
    RCS file: /cvs/jogl/src/net/java/games/gluegen/cgram/types/CompoundType.java,v
    retrieving revision 1.2
    diff -u -r1.2 CompoundType.java
      • src/net/java/games/gluegen/cgram/types/CompoundType.java 14 Jul 2003
        05:34:51 -0000 1.2
        +++ src/net/java/games/gluegen/cgram/types/CompoundType.java 2 Apr 2005
        09:02:11 -0000
        @@ -88,6 +88,8 @@
        if (arg == null || (!(arg instanceof CompoundType))) { return false; }

        + if (arg.hashCode() != hashCode())
        + return false;
        CompoundType t = (CompoundType) arg;
        return (super.equals(arg) &&
        kind == t.kind &&



 Comments   
Comment by kbr [ 04/Apr/05 ]

Submitted patches had a couple of problems. First, the removal of the
(incorrect) cast to const char* in the CMethodBindingEmitter caused
build warnings on other platforms. Fixed these by making the const
declarations correct for the conversion case of String[] -> char**.
Second, addition of comparison of hashCodes in CompoundType.equals()
seemed like too much of a hack. Fixed this by correcting potential
problems in equals() and hashCode() methods; not sure whether this
will solve the submitter's original problem, though.

The applied diffs have been added as an attachment.

Comment by kbr [ 04/Apr/05 ]

Created an attachment (id=41)
diffs applied to tree





[JOGL-128] Two Animator threads controlling two GLCanvas objects deadlock, or one of the threads starve. Created: 07/Jan/05  Updated: 30/Apr/05  Resolved: 30/Apr/05

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

Type: Bug Priority: Blocker
Reporter: direwolf 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 Main.java     Java Source File Main.java     Java Source File Main.java    
Issuezilla Id: 128

 Description   

Problem:
It appears that two Animator threads controlling two GLCanvas objects deadlock,
or one of the threads starve.

Description:
This problem occurs when a single JFrame contains two JPanel's that each contain
a GLCanvas controled by an Animator thread. Three behaviors have been observed:
Both threads will deadlock; One thread will run and the other will starve; Both
threads run.

When both threads run, no exceptions are thrown and both panels will render with
animation, but other bugs crop up. I've noticed that JMenuItem won't render
until it is highlighted.

When one of the animation threads is starved, the following exception is thrown:

Exception in thread "Thread-3" java.lang.NullPointerException
at
net.java.games.jogl.impl.windows.WindowsGLContextFactory.getDummyGL(WindowsGLContextFactory.java:117)
at
net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext(WindowsGLContext.java:279)
at
net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.create(WindowsOnscreenGLContext.java:211)
at
net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:135)
at
net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:110)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:250)
at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:208)
at net.java.games.jogl.GLCanvas.display(GLCanvas.java:75)
at net.java.games.jogl.Animator$1.run(Animator.java:107)
at java.lang.Thread.run(Thread.java:595)

Code Example:
import net.java.games.jogl.*;
import java.awt.*;
import java.awt.event.*;
import java.beans.*;

import javax.swing.*;
import javax.swing.event.*;

public class Main extends javax.swing.JFrame {
private JMenuBar menubar;
private JMenu fileMenu;
private JMenuItem fileExit;
private JPanel leftPanel, rightPanel;
private JSplitPane splitPane;
private TestPanel panel1, panel2;

public static void main(String args[]) {
EventQueue.invokeLater(new Runnable() {
public void run()

{ new Main().setVisible(true); }

});
}

public Main() {
GLCapabilities cap=new GLCapabilities();
cap.setHardwareAccelerated(true);
cap.setDoubleBuffered(false);

// This call ensures that the JMenuBar will render over the GLCanvas.
JPopupMenu.setDefaultLightWeightPopupEnabled(false);

// Create components.
splitPane = new JSplitPane();
leftPanel = new JPanel();
rightPanel = new JPanel();
menubar = new JMenuBar();
fileMenu = new JMenu();
fileExit = new JMenuItem();

setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
leftPanel.setLayout(new BorderLayout());
leftPanel.setPreferredSize(new Dimension(400, 600));
splitPane.setLeftComponent(leftPanel);
rightPanel.setLayout(new BorderLayout());
splitPane.setRightComponent(rightPanel);

getContentPane().add(splitPane, BorderLayout.CENTER);

fileMenu.setText("File");
fileExit.setText("Exit");
fileExit.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent evt)

{ fileExitActionPerformed(evt); }

});

fileMenu.add(fileExit);
menubar.add(fileMenu);
setJMenuBar(menubar);

panel1 = new TestPanel();
panel2 = new TestPanel();
leftPanel.add(panel1, BorderLayout.CENTER);
rightPanel.add(panel2, BorderLayout.CENTER);

pack();

setSize(800, 600);

// Start the animation on panel 1.
panel1.start();

/******************************************************
// When we attempt to start the animation on panel 2, the
// program will either lock up or the program will run but
// panel2 won't render. It's clear that the two animator
// threads are competing for some resource, causing a
// deadlock or causing the second thread to starve.
******************************************************/
panel2.start();

}

private void fileExitActionPerformed(ActionEvent evt)

{ System.exit(0); }

public class TestPanel extends JPanel {
GLCanvas canvas;
Animator animator;

public TestPanel()

{ // The JPanel must use the Border layout manager. setLayout(new java.awt.BorderLayout()); // Create the GLCanvas. canvas = GLDrawableFactory.getFactory().createGLCanvas(new GLCapabilities()); canvas.addGLEventListener(new TestRenderer()); // Create an animator thread for the canvas. animator = new Animator(canvas); // Add the canvas to the center of the JPanel. add(canvas); // We need to create a Dimension object for the JPanel minimum size to fix a GLCanvas resize bug. // The GLCanvas normally won't recieve resize events that shrink a JPanel controled by a JSplitPane. setMinimumSize(new Dimension()); }

public void start()

{ animator.start(); }

public void stop()

{ animator.stop(); }

class TestRenderer implements GLEventListener {
private GL gl;
private GLDrawable gldrawable;
float angle = 0;

public void init(GLDrawable drawable)

{ gl = drawable.getGL(); this.gldrawable = drawable; }

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

{ gl. glViewport(0, 0, width, height); }

public void display(GLDrawable drawable)

{ gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT); gl.glRotatef(angle, 0f, 0f, 1f); angle += 2; gl.glBegin(GL.GL_POLYGON); gl.glVertex2f(-0.5f, -0.5f); gl.glVertex2f(-0.5f, 0.5f); gl.glVertex2f(0.5f, 0.5f); gl.glVertex2f(0.5f, -0.5f); gl.glEnd(); }

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



 Comments   
Comment by direwolf [ 07/Jan/05 ]

Created an attachment (id=23)
Example program which renders two rotating squares in two JFrames contained in a JSplitPane.

Comment by direwolf [ 08/Jan/05 ]

Created an attachment (id=24)
A better example. This one creates two JSplitFrames and three JPanels. The animator threads are started when the user selects the Test/Start All menu item. Sometimes it works, sometimes it doesn't.

Comment by kbr [ 30/Apr/05 ]

Created an attachment (id=46)
Working version of test case

Comment by kbr [ 30/Apr/05 ]

I can't reproduce any deadlock with JOGL 1.1 b10 but can see the other reported
behavior like the menus not repainting. The latter appears to be due solely to
the CPU being starved. Creating a custom animation thread and drawing the three
canvases in turn works, and has the added side effect that the start and stop
menu items work all the time and don't throw any exceptions.





[JOGL-127] Build is failing Created: 04/Jan/05  Updated: 27/Jan/05  Resolved: 27/Jan/05

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

Type: Bug Priority: Blocker
Reporter: crippleman 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: All


Issuezilla Id: 127

 Description   

the build for jogl fails on my computer. the fail message is:
BUILD FAILED: C:\Documents and Settings\jimmy
ventura\Desktop\WorkSpace\jogl\make\build.xml:356: The following error occurred
while executing this line:
C:\Documents and Settings\jimmy ventura\Desktop\WorkSpace\jogl\make\validate-
properties.xml:13:
*****************************************************************

    • The property "antlr.jar" was not set in the JOGL properties **
    • file **
    • "C:\Documents and Settings\jimmy ventura/jogl.properties"
      **
    • (or this file was not found). **
    • **
    • Please set "antlr.jar" to to the full path of the ANTLR jar **
    • including the jar itself. **
      *****************************************************************
      i checked it several times and the properties files has the correct route for
      the jar
      (antlr.jar=C:\Documents and Settings\All Users\antlr-2.7.4\antlr.jar)
      note: currently i am using antlr-2.7.4 and ant 1.6.2
      can someone corraborate this issue... i would be thankful


 Comments   
Comment by kbr [ 04/Jan/05 ]

This may be due to the space in the path to either the JOGL workspace or to the
properties file, or possibly due to a missing jogl.properties file. Check the
full path to the jogl.properties file, ensure you have copied it into the
correct place, and that it contains the antlr.jar property. If it is present,
try building the workspace as a different user name which does not contain a
space. I'm not sure we can do anything about the build failing if spaces are
present in the paths; many programs have problems with Windows paths containing
spaces.

Comment by kbr [ 27/Jan/05 ]

I'm closing this bug as not reproducible. There may be issues with spaces in the
build.xml but due to how it and Ant work I don't think there's anything we can
do about that.





[JOGL-120] Hole in gluSphere Created: 19/Nov/04  Updated: 19/Nov/04  Resolved: 19/Nov/04

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

Type: Bug Priority: Blocker
Reporter: gusgus84 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: 120

 Description   

Using the latest GLU implementation (borrowed from LWJGL) gluSphere will now
create spheres with holes in them (alligned with the Z-axis). The hole's size
depends on the stacks variable (a low number of stacks will yield a large hole,
and a high number of stacks will yield a small hole) The only workaround I've
seen so far is to increase the # of stacks past 300 which is very slow to render
compared to the 10 I normally use.



 Comments   
Comment by kbr [ 19/Nov/04 ]

This has already been fixed in the CVS repository and in the 1.1 b07 builds just
released.





[JOGL-115] GLDrawable.swapBuffers(); behaviour Created: 22/Oct/04  Updated: 31/Jan/05  Resolved: 31/Jan/05

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

Type: Bug Priority: Blocker
Reporter: skippy 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


Issuezilla Id: 115

 Description   

windowed + automatic-swap = only dark-green box (as expected)
fullscreen + automatic-swap = only dark-green box (as expected)

forced-swap + canvas.setAutoSwapBufferMode(true); combo
(which is wrong, but shows the unpredicted behaviour)
windowed + forced-swap = dark/bright green boxes flicking (hm...)
fullscreen + forced-swap = only dark-green box (hm...)
^^^^^^^^^^ both should result in the same gfx, but are different.

What happens:
in fullscreen-mode the swapBuffers() is ignored (correct)
in windowed-mode the swapBuffer() is processed (wrong, as: canvas.
setAutoSwapBufferMode(true))

forced-swap + canvas.setAutoSwapBufferMode(false); combo works just fine.

import java.awt.*;
import java.awt.event.*;
import javax.swing.JOptionPane;
import javax.swing.UIManager;

import net.java.games.jogl.*;

public class Run
{
public static void main(String[] args) throws Exception

{ new Run(); }

private Run()
{
try

{ UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); }

catch (Exception exc)

{ // }

// Settings

final boolean fullscreen = JOptionPane.OK_OPTION == JOptionPane.
showConfirmDialog(new Frame(), "Do you want to enter fullscreen-mode?",
"Fullscreen?", JOptionPane.YES_NO_OPTION);

try
{ Thread.sleep(500); }
catch (Exception exc)
{ // }

final boolean forcedSwap = JOptionPane.OK_OPTION == JOptionPane.
showConfirmDialog(new Frame(), "Do you want to forcibly swap buffers?",
"ForcedSwap?", JOptionPane.YES_NO_OPTION);

// GUI

final GLCapabilities caps = new GLCapabilities();
caps.setHardwareAccelerated(true);

final GLCanvas canvas = GLDrawableFactory.getFactory().
createGLCanvas(caps);

/*

  • If this mode is set to true, whatever the "forcedSwap" value might be,
  • behaviour changes in fullscreen/windowed-mode.
    */
    canvas.setAutoSwapBufferMode(true);
    // Should be: [!forcedSwap] in perfect code

canvas.setNoAutoRedrawMode(true);
canvas.addGLEventListener(new Renderer(forcedSwap));
canvas.addKeyListener(new KeyboardShutdown());

final Frame frame = new Frame();
frame.setTitle("Bouncing box");
frame.setResizable(false);
frame.add(canvas, BorderLayout.CENTER);

if (fullscreen)

{ frame.setUndecorated(true); GraphicsEnvironment env = GraphicsEnvironment. getLocalGraphicsEnvironment(); GraphicsDevice device = env.getDefaultScreenDevice(); device.setFullScreenWindow(frame); }

else

{ frame.setSize(640, 480); frame.setLocationRelativeTo(null); frame.setVisible(true); }

frame.addWindowListener(new FrameShutdown());

canvas.requestFocus();

running = true;
n00bL00p(frame, canvas);
}

/**

  • LOOP
    */

private boolean running;

private void n00bL00p(Frame frame, GLCanvas canvas)
{
while (running)

{ logic(); canvas.display(); }

// Close
frame.setVisible(false);
frame.dispose();
System.exit(0);
}

/**

  • LOGIC
    */

private int w, h;

private int rectX, rectY, rectR, rectSpeedX, rectSpeedY;

private void logic()
{
rectX += rectSpeedX;
rectY += rectSpeedY;

if (rectX < 0 || rectX > w)

{ rectSpeedX *= -1; }

if (rectY < 0 || rectY > h)

{ rectSpeedY *= -1; }

}

/**

  • RENDERER
    */

private class Renderer implements GLEventListener
{
private final boolean forcedSwap;

public Renderer(boolean forcedSwap)

{ this.forcedSwap = forcedSwap; }

public void init(GLDrawable d)

{ GL gl = d.getGL(); gl.glShadeModel(GL.GL_SMOOTH); gl.glClearColor(0.0F, 0.0F, 0.0F, 1.0F); rectR = 32; rectSpeedX = 4; rectSpeedY = 4; }

public void display(GLDrawable d)
{
GL gl = d.getGL();

// Bright green box
this.renderBox(gl, rectX - rectR, rectY, rectR, new float[]

{ 0.0F, 1. 0F, 0.0F }

);

if (forcedSwap)

{ // Swap in-between d.swapBuffers(); }

// Dark green box
this.renderBox(gl, rectX + rectR, rectY, rectR, new float[]

{ 0.0F, 0. 5F, 0.0F }

);

if (forcedSwap)

{ // Swap finally d.swapBuffers(); }

}

private void renderBox(GL gl, int x, int y, int r, float[] color)
{
gl.glClear(GL.GL_COLOR_BUFFER_BIT);

this.enable2D(gl);

gl.glColor3fv(color);
gl.glBegin(GL.GL_QUADS);
gl.glVertex2f(x - r, y - r);
gl.glVertex2f(x + r, y - r);
gl.glVertex2f(x + r, y + r);
gl.glVertex2f(x - r, y + r);
gl.glEnd();

this.disable2D(gl);

try

{ Thread.sleep(10L); }

catch (Exception exc)

{ // Terrible I know, just for testing. }

}

public void displayChanged(GLDrawable arg0, boolean arg1, boolean arg2)

{ // }

public void reshape(GLDrawable arg0, int arg1, int arg2, int arg3, int
arg4)

{ w = arg3; h = arg4; }

private final void enable2D(GL gl)

{ // Java2D coord-system gl.glMatrixMode(GL.GL_PROJECTION); gl.glPushMatrix(); gl.glLoadIdentity(); gl.glScalef(1.0F / (w / 2), 1.0F / (h / 2), 1); gl.glTranslatef(-w / 2, h / 2, 0); gl.glScalef(1, -1, 1); gl.glMatrixMode(GL.GL_MODELVIEW); gl.glPushMatrix(); gl.glLoadIdentity(); }

private final void disable2D(GL gl)

{ gl.glMatrixMode(GL.GL_PROJECTION); gl.glPopMatrix(); gl.glMatrixMode(GL.GL_MODELVIEW); gl.glPopMatrix(); }

}

/**

  • SHUT DOWN
    */

private class FrameShutdown extends WindowAdapter
{
public void windowClosing(WindowEvent event)

{ running = false; }

}

private class KeyboardShutdown extends KeyAdapter
{
public void keyPressed(KeyEvent event)
{
if (event.getKeyCode() == KeyEvent.VK_ESCAPE)

{ running = false; }

}
}
}



 Comments   
Comment by kbr [ 31/Jan/05 ]

I can't reproduce this behavior. Fullscreen and windowed mode work identically
on my machine (Windows XP, NVidia Quadro FX Go700). The code should be
specifying canvas.setAutoSwapBufferMode(!forcedSwap) as far as I can tell in
order for it to exhibit the intended behavior. Regardless, as long as
sync-to-vertical-refresh is enabled, both boxes are shown.





[JOGL-105] FSAA not supported on Radeon 9700 Created: 30/Aug/04  Updated: 31/Jan/05  Resolved: 31/Jan/05

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

Type: Bug Priority: Blocker
Reporter: fmpc77 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


Issuezilla Id: 105

 Description   

I cant get a pixel format that enable multisample with my radeon
9700/XP/lattestDrivers/currentJoglVersion... A bit annoying. I'll check WGL
pixel format selection code to see if I can help (even if i am new here .
Thanks to study it



 Comments   
Comment by kbr [ 31/Jan/05 ]

This works for me (ATI Radeon 9800 Pro, Windows XP, latest JOGL sources from
CVS, which will become 1.1 b08 shortly). Does demos.multisample.Multisample in
the jogl-demos workspace work for you? Please reopen this bug if things still do
not work once 1.1 b08 comes out.





[JOGL-90] Two JInternalFrames with Animators crash with EXCEPTION_ACCESS_VIOLATION Created: 29/May/04  Updated: 31/Jan/05  Resolved: 31/Jan/05

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

Type: Bug Priority: Blocker
Reporter: nikojn Assignee: kbr
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


Issuezilla Id: 90

 Description   

Two JInternalFrames are added to a JDesktopPane. Both of them have GLCanvases
controlled by Animators. Moving one of the windows on the desktop causes a non-
recoverable error, a crash with the following trace:

net.java.games.jogl.GLException: Error swapping buffers
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.swapBuffers
(WindowsOnscreenGLContext.java:140)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:270)
at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:186)
at net.java.games.jogl.GLCanvas.display(GLCanvas.java:74)
at net.java.games.jogl.Animator$1.run(Animator.java:104)
at java.lang.Thread.run(Thread.java:534)

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
PC=0x693F21F6
Function=[Unknown.]
Library=G:\windows\System32\atioglxx.dll

NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.

Current Java thread:
at
net.java.games.jogl.impl.windows.WindowsGLImpl.dispatch_wglChoosePixelFormatARB
(Native Method)
at
net.java.games.jogl.impl.windows.WindowsGLImpl.wglChoosePixelFormatARB
(WindowsGLImpl.java:33092)
at
net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateCont
ext(WindowsGLContext.java:342

The environment is:

  • JOGL nightly build dated 20040517
  • WinXP
  • ATI Radeon 9700 Pro, with 4.5 Catalyst drivers
  • J2SE 1.4.2_04

Note: this issue probably somewhat overlaps with the existing issue #30.
Here is the complete source code for the test case:

— snip —
import net.java.games.jogl.*;

import javax.swing.*;

public class GLCanvasTest
implements GLEventListener
{
public static void main(String[] args)

{ new GLCanvasTest().test(); }

public GLCanvasTest()
{
}

public void test()

{ JFrame jFrame = new JFrame("Main Window"); jFrame.setSize(640, 480); jFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); JDesktopPane jDesktopPane = new JDesktopPane(); createChildWindow(jDesktopPane, "Child Window #1"); createChildWindow(jDesktopPane, "Child Window #2"); jFrame.setContentPane(jDesktopPane); jFrame.show(); }

private JInternalFrame createChildWindow(JDesktopPane jDesktopPane, final
String title)
{
final JInternalFrame jInternalFrame = new JInternalFrame(title, true,
true, true, true);
jInternalFrame.setSize(320, 200);
jInternalFrame.setLocation(jDesktopPane.getAllFrames().length * 200,
jDesktopPane.getAllFrames().length * 200);

GLCapabilities glCaps = new GLCapabilities();
glCaps.setDoubleBuffered(true);
glCaps.setHardwareAccelerated(true);
GLCapabilitiesChooser glCapsChooser = new DefaultGLCapabilitiesChooser
();

GLCanvas glCanvas = GLDrawableFactory.getFactory().createGLCanvas
(glCaps, glCapsChooser);
glCanvas.addGLEventListener(this);

jInternalFrame.getContentPane().add(glCanvas);
jInternalFrame.show();
jDesktopPane.add(jInternalFrame);

final Animator animator = new Animator(glCanvas);
new Thread()
{
public void run()
{
try

{ sleep(1000); }

catch (InterruptedException ignored)
{
}
animator.start();
jInternalFrame.setTitle(title + ", started");
}
}.start();

return jInternalFrame;
}

public void init(GLDrawable glDrawable)
{
}

public void display(GLDrawable glDrawable)

{ GL gl = glDrawable.getGL(); gl.glClearColor((System.currentTimeMillis() % 1000) / 1000.0f, 0.0f, 0.0f, 0.0f); gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT); }

public void reshape(GLDrawable glDrawable, int i, int i1, int i2, int i3)
{
}

public void displayChanged(GLDrawable glDrawable, boolean b, boolean b1)
{
}
}
— snip —



 Comments   
Comment by kbr [ 31/Jan/05 ]

This problem is caused by bugs in ATI's OpenGL drivers. The test case works on
NVidia hardware. Bug fixes and additional workarounds have recently been checked
in to the single-threaded workaround designed for ATI hardware. The attached
test case works properly with the code in the CVS repository, which will be
introduced in JOGL 1.1 b08.





[JOGL-85] Weekly builds / source Created: 07/May/04  Updated: 16/Jul/04  Resolved: 16/Jul/04

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

Type: Improvement Priority: Blocker
Reporter: petermantell 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: 85

 Description   

We have a firewall here that prevents us from accessing CVS. So to get the JOGL
source we need to go to a different machine, do a CVS checkout, then burn the
results to a CD to transfer them into the network.

I find this prohibitively difficult - it takes too long to do on the off chance
that it might fix the problems I have with JOGL.

Firewalls aside, do you guys really want it to be difficult for people to use
your product? Doing a cvs checkout is hardly simple if you're a new user.

So I suggest that you start to provide weekly (or appropriately frequent)
packages of JOGL, either containing source code or even platform specific
builds.

This will help industry acceptance of JOGL. I'm sorry, but if its hard to get
at, I just won't bother.

Pete



 Comments   
Comment by kbr [ 16/Jul/04 ]

Support for building source archives for the jogl and jogl-demos workspaces has
been added to the respective build.xml files. Forthcoming beta and final JOGL
releases will contain source archives. The nightly build system needs
maintenance work to utilize this support, so for now please look to the official
releases.

Comment by kbr [ 16/Jul/04 ]
      • Issue 83 has been marked as a duplicate of this issue. ***




[JOGL-72] Memory Leak Manually Calling repaint() Created: 10/Apr/04  Updated: 11/Apr/04  Resolved: 11/Apr/04

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

Type: Bug Priority: Blocker
Reporter: sunsett 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: All


Issuezilla Id: 72

 Description   

When a frame is visible and repaint() is being called manually the memory usage
continues to increase until it is minimized or closed. This needs to be dealt
with immediately as any games that expect long-term playing will eventually run
out of memory.

Please see the following example code that shows this:

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import net.java.games.jogl.*;

public class TestJOGL extends WindowAdapter implements GLEventListener{
private GL gl;
private GLDrawable drawable;
private Animator animator;
private Thread updater;
private GLCanvas canvas;

public static void main(String args[]) throws Exception

{ new TestJOGL(); }

public TestJOGL() throws Exception {
JFrame frame = new JFrame("Test JOGL");
frame.setSize(512, 384);
GLCapabilities capabilities = new GLCapabilities();
capabilities.setRedBits(8);
capabilities.setBlueBits(8);
capabilities.setGreenBits(8);
capabilities.setAlphaBits(8);
this.canvas = GLDrawableFactory.getFactory().createGLCanvas
(capabilities);
canvas.addGLEventListener(this);
frame.add(canvas);
frame.addWindowListener(this);
frame.setVisible(true);
updater = new Thread() {
public void run() {
try {
int sleep = 1000 / 60;
while (true)

{ canvas.repaint(); Thread.sleep(sleep); }

} catch(InterruptedException e)

{ e.printStackTrace(); }

}
};
updater.start();
}

public void init(GLDrawable drawable)

{ this.gl = drawable.getGL(); this.drawable = drawable; drawable.setGL(new DebugGL(drawable.getGL())); System.out.println("Init GL is " + gl.getClass().getName()); }

public void display(GLDrawable drawable)

{ gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT); gl.glLoadIdentity(); gl.glColor3f(0.5f, 0.0f, 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(); gl.glColor3f(1.0f, 0.5f, 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(); gl.glColor3f(0.0f, 0.0f, 1.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(); gl.glColor3f(1.0f, 0.0f, 1.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(); }

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

{ System.out.println("Reshape called!"); }

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

public void windowClosing(WindowEvent e)

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

}



 Comments   
Comment by kbr [ 10/Apr/04 ]

There is definitely a slow memory leak but it isn't clear where it is. It does
not appear to be a leak in the Java heap as -verbose:gc does not show any
growth. Most likely the leak is in either the code that interacts with the JAWT
or in the JAWT implementation itself, though this is hopefully unlikely. Should
run this test on X11.

Comment by kbr [ 11/Apr/04 ]

Upon further investigation I can not reproduce this problem. The memory usage of
the application starts at roughly 18800K and grows within the first couple of
minutes to about 19500K, but then stabilizes. Adding the ability to do a full GC
upon a keypress didn't change the behavior, so this growth isn't due to
finalizable or reference objects that need to be cleared / cleaned up in order
to reclaim native machine resources. Windows XP Professional, NVidia GeForce
Quadro FX 700 Go, 44.24 drivers. Please reopen this bug or start a new bug with
complete OS, graphics card, and driver information if you see different behavior.





[JOGL-67] Java/Jogl app hangs some systems, not others, during reshape. Created: 10/Mar/04  Updated: 12/May/05  Resolved: 12/May/05

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

Type: Bug Priority: Blocker
Reporter: pdjensen 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://agileimage.com/html/statistics/TimeMachine.jnlp


Attachments: JPEG File bad.jpg     JPEG File good.jpg    
Issuezilla Id: 67

 Description   

I have been trying to track down a strange jogl lighting problem on some systems which can also
reliably cause some of them to hang. The problem is fairly consistent on a 1.33 Ghz Powerbook with
the latest OS, Java, tools, and Gregory Pierce's version of jogl (Feb 17, Optimized, but the problem has
been there for at least several weeks, if not all along). I also see the problem with the Sep 2003 Win32
libray from the games games-core jogl site.

The systems it has hung are new Mac 15" & 17" PB's, a dual cpu G5, and a Win2K system with an ATI
Rage 128 VR card. It does not seem to be a problem on Mac 12" PB, iMac, or iBook.

You can see the problem by running the JWS app:

http://agileimage.com/html/statistics/TimeMachine.jnlp

Lighting:

In the Window menu, select the last entry (bea/USPopulation.csv) and observe that only three states
appear to be lit properly - the rest have just ambient light. Move the slider at the bottom and see the
lighting fix itself when Alaska and Hawaii appear. Move the slider back to the beginning and the
problem reappears. Select the View/Display/Top 30 and about half are lit ok, Bottom 30 and just 2 are
ok, etc.

Reshape hangs sytem:

Resize the window larger and the familiar old resize bug appears where some of the window is not
being rendered, no big deal. But move the split pane divider to make the map less than 32 pixels high,
and some systems will hang so that the mouse still moves, but nothing responds. I have to reboot.
There is a System.err output to report the reshape size so you can tell when you are close.

I'm trying to get some idea of how to track down these problems. I use the Animator, changing the
model in the AWT event thread and then updating a reference to the set of call lists to be displayed by
the Animator. The display code for each state (one call list per state) is this, where the color c is defined
by the state (unless highlighted or hidden):

gl.glPushMatrix();
gl.glScaled( xScale, yScale, visible? zScale * value / maxValue: 0.0 );
gl.glTranslatef( -longCenter, -latCenter, 0f );
gl.glMaterialfv(GL.GL_FRONT, GL.GL_AMBIENT_AND_DIFFUSE, c);
gl.glCallList( j );
gl.glPopMatrix();

The directional light source is Light0Position =

{ -1.0f, 2.0f, 2.0f, 0.0f }

;

The reshape code was lifted fairly directly from the Jogl Gears demo.



 Comments   
Comment by kbr [ 28/Jan/05 ]

Is this problem still reproducible? Many bugs have been fixed since this issue
was reported, including a workaround for ATI cards that reduces OpenGL rendering
to running on a single thread. The latest CVS sources contain a bug fix to Issue
97, which turned out to be a bug in this single-threaded workaround. The current
JOGL seems to be fairly robust on my ATI Radeon 9800 Pro. (There is still an
outstanding issue with multiple GLCanvas creation on ATI cards: Issue #118.)

If the problem is still reproducible, could you please attach a test case to
this bug report? Thanks.

Comment by kbr [ 31/Jan/05 ]

Comments from pdjensen:


I apologize for not following up earlier. Most of the issues described in this
bug report are fixed now with the exception that on my Mac 17" 1.33 GHz
PowerBook, the repaint leaves sections that are garbage.

The lighting problem was my bug.

The crashes when resizing to less than a dozen pixels in height no longer happen
with JOGL of Nov 19, 2004 on either the PowerBook or my Win2K system. (By the
way, I am looking forward to signed JOGL libraries with versions - I'm still
re-signing your stuff to maintain control over which version I use).

The repaint problem has been with me for as long as I've used JOGL. It does
appear that it is no longer a problem on my Win2K system. I am attaching
snapshots of the problem. "bad.jpg" is the result of making the application
window larger. "good.jpg" is the correct view after moving the divider between
the JOGL pane and Swing pane just slightly. The width did not change despite the
snapshots - the two images were scaled differently when I converted the tiff
screen captures.

The video card on the PowerBook is an ATI MOBILITY RADEON 9600.


Comment by kbr [ 31/Jan/05 ]

Created an attachment (id=34)
Screenshot of bad behavior on ATI adapter

Comment by kbr [ 31/Jan/05 ]

Created an attachment (id=35)
Screenshot of proper behavior

Comment by kbr [ 11/May/05 ]

With the latest changes to the GLCanvas's resizing code on Mac OS X in JOGL 1.1
b11 I believe all remaining resizing issues should be fixed. Could you please
retest your application? Thanks.

Comment by kbr [ 12/May/05 ]

Submitter has indicated that the recent fix on Mac OS X to always update the
context even if the GLCanvas has not been resized has solved all remaining problems.





[JOGL-60] Bug fix in tessellation for vertex[Data] callbacks, jogl from Sep 2003 Created: 29/Jan/04  Updated: 29/Jan/04  Resolved: 29/Jan/04

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

Type: Bug Priority: Blocker
Reporter: pdjensen 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: 60

 Description   

In net.java.games.jogl.impl.tesselator.Render.java:306 in renderLonelyTriangle() of the
Sept 5 release, the line
 
      tess.callVertexOrVertexData( e.Org.data);
 
should be
 
      tess.callVertexOrVertexData( e.Org.coords);
 
The vertex(coords) and vertexData(coords, userData) callbacks were getting the
userData information in place of the coords.



 Comments   
Comment by kbr [ 29/Jan/04 ]

Thanks for the patch. This has been fixed in the CVS repository.

Comment by kbr [ 29/Jan/04 ]

pepijnve pointed out that the original behavior is by design.

Comment by kbr [ 29/Jan/04 ]

pepijnve pointed out that this behavior is by design.





[JOGL-58] GLCanvas draws over other components in MacOS X Created: 17/Jan/04  Updated: 18/Jan/04  Resolved: 18/Jan/04

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

Type: Bug Priority: Blocker
Reporter: daw 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: Mac OS X
Platform: Macintosh


Attachments: Java Source File TestProgram.java    
Issuezilla Id: 58

 Description   

When adding multiple panels into a frame where components do not overlap, the
GLCanvas occupies the entire frame, drawing over the other panels under Mac OS X. The
problem does not appear to exist under Linux. An example is included below. On MacOS
X (10.2.8), the buttonPanel is not visible, however, under Linux, the buttonPanel is visible.

------- Test Program --------

import net.java.games.jogl.*;
import javax.swing.*;
import java.awt.*;

public class TestProgram {

private static class Renderer implements GLEventListener {

public void display( GLDrawable drawable )

{ GL gl = drawable.getGL(); gl.glClear(GL.GL_COLOR_BUFFER_BIT); gl.glMatrixMode(GL.GL_MODELVIEW); gl.glLoadIdentity(); gl.glBegin( GL.GL_TRIANGLES ); gl.glVertex2d(-1.0, -1.0 ); gl.glVertex2d(1.0, -1.0); gl.glVertex2d(0.0, 1.0); gl.glEnd(); gl.glFlush(); }

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

public void init(GLDrawable drawable) {}

public void reshape( GLDrawable drawable, int x, int y, int w, int h)

{ GL gl = drawable.getGL(); gl.glMatrixMode(GL.GL_PROJECTION); gl.glLoadIdentity(); gl.glOrtho(-2.0, 2.0, -2.0, 2.0, -1, 1 ); }

}

public static void main( String[] args )

{ JFrame frame = new JFrame(); JPanel mainPanel = new JPanel(); mainPanel.setLayout( new BorderLayout() ); Renderer rend = new Renderer(); GLCanvas can = GLDrawableFactory.getFactory().createGLCanvas(new GLCapabilities()); can.addGLEventListener( rend ); mainPanel.add(can, BorderLayout.CENTER ); JPanel buttonPanel = new JPanel(); buttonPanel.add( new JButton("Button One") ); buttonPanel.add( new JButton("Button Two") ); mainPanel.add(buttonPanel, BorderLayout.SOUTH); frame.getContentPane().add(mainPanel); frame.setSize( 400,400); frame.show(); }

}



 Comments   
Comment by daw [ 17/Jan/04 ]

Created an attachment (id=11)
Test program that demonstrates the issue. Run under MacOS X.

Comment by gziemski [ 18/Jan/04 ]

This is working for me.

You need to either get the 1.4.2 DP2 (or the final when it is released), or install Java3D on top of
JDK1.4.1. Java3D comes with updated libjawt.dylib which is where the problem was.





[JOGL-30] Error Swapping Buffers with JInternalFrame Created: 07/Aug/03  Updated: 31/Jan/05  Resolved: 31/Jan/05

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

Type: Bug Priority: Blocker
Reporter: moussaba 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 Archive File lesson06.jar     Java Source File Lesson06.java     Java Source File Lesson06.java    
Issuezilla Id: 30

 Description   

When GLcanvas added to a JInternalFrame, when frame is iconized and restored it
crashes and generates the following exception:

net.java.games.jogl.GLException: Error swapping buffers
at
net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.swapBuffers
(WindowsOnscreenGLContext.java:137)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:187)
at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:179)
at net.java.games.jogl.GLCanvas.display(GLCanvas.java:84)
at net.java.games.jogl.Animator$1.run(Animator.java:104)
at java.lang.Thread.run(Thread.java:534)

Below is example source code that generates the exception

*

  • Lesson06.java
  • Modified on August 07, 2003
  • Reproduces the GLException: Error Swapping Buffers when
  • Using JInternalFrame. Iconize the Internal Frame, restore it and you will
  • get the above mentioned exception. This does not occur when the main window
  • is iconized.
  • Created on July 16, 2003, 11:30 AM
  • Modified on August 97,2003
    */

import java.awt.*;
import java.awt.event.*;
import java.awt.image.*;
import javax.swing.*;
import javax.swing.event.*;
import java.io.*;
import java.net.*;
import java.nio.*;
import javax.imageio.*;

import net.java.games.jogl.*;
import net.java.games.jogl.util.*;

/** Port of the NeHe OpenGL Tutorial (Lesson 6)

  • to Java using the Jogl interface to OpenGL. Jogl can be obtained
  • at http://jogl.dev.java.net/
    *
  • @author Kevin Duling (jattier@hotmail.com)
    */
    public class Lesson06
    {
    static Animator animator = null;
    static class Renderer
    implements GLEventListener,
    KeyListener
    {
    private float xrot; // X Rotation ( NEW )
    private float yrot; // Y Rotation ( NEW )
    private float zrot; // Z Rotation ( NEW )
    private int[] texture= new int[2];

/** Called by the drawable to initiate OpenGL rendering by the client.

  • After all GLEventListeners have been notified of a display event, the
  • drawable will swap its buffers if necessary.
  • @param gLDrawable The GLDrawable object.
    */
    public void display(GLDrawable gLDrawable) { final GL gl = gLDrawable.getGL(); gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT); gl.glLoadIdentity(); // Reset The View gl.glTranslatef(0.0f,0.0f,-5.0f); gl.glRotatef(xrot,1.0f,0.0f,0.0f); gl.glRotatef(yrot,0.0f,1.0f,0.0f); gl.glRotatef(zrot,0.0f,0.0f,1.0f); gl.glColor3f(1.0f, 1.0f, 1.0f); gl.glBindTexture(GL.GL_TEXTURE_2D, texture[0]); gl.glBegin(GL.GL_QUADS); //Bottom of Cube gl.glTexCoord2f(1.0f, 1.0f); gl.glVertex3f(-1.0f, -0.25f, -1.0f); gl.glTexCoord2f(0.0f, 1.0f); gl.glVertex3f( 1.0f, -0.25f, -1.0f); gl.glTexCoord2f(0.0f, 0.0f); gl.glVertex3f( 1.0f, -0.25f, 1.0f); gl.glTexCoord2f(1.0f, 0.0f); gl.glVertex3f(-1.0f, -0.25f, 1.0f); gl.glEnd(); gl.glBindTexture(GL.GL_TEXTURE_2D, texture[1]); gl.glBegin(GL.GL_QUADS); // Top Face gl.glTexCoord2f(0.0f, 1.0f); gl.glVertex3f(-1.0f, 0.0f, -1.0f); gl.glTexCoord2f(0.0f, 0.0f); gl.glVertex3f(-1.0f, 0.0f, 1.0f); gl.glTexCoord2f(1.0f, 0.0f); gl.glVertex3f( 1.0f, 0.0f, 1.0f); gl.glTexCoord2f(1.0f, 1.0f); gl.glVertex3f( 1.0f, 0.0f, -1.0f); gl.glBegin(GL.GL_QUADS); /*gl.glTexCoord2f(0.0f, 0.0f); gl.glVertex3f(-1.0f, -1.0f, 1.0f); gl.glTexCoord2f(1.0f, 0.0f); gl.glVertex3f( 1.0f, -1.0f, 1.0f); gl.glTexCoord2f(1.0f, 1.0f); gl.glVertex3f( 1.0f, 1.0f, 1.0f); gl.glTexCoord2f(0.0f, 1.0f); gl.glVertex3f(-1.0f, 1.0f, 1.0f); */ // Back Face gl.glColor3f(0.0f, 0.4f, 0.0f); // Set The Color To Blue gl.glVertex3f(1.0f, -0.25f, -1.0f); // Top Right Of The Quad (Back) gl.glVertex3f( -1.0f, -0.25f, -1.0f); // Top Left Of The Quad (Back) gl.glVertex3f( -1.0f, 0.0f, -1.0f); // Bottom Left Of The Quad (Back) gl.glVertex3f(1.0f, 0.0f, -1.0f); // Bottom Right Of The Quad (Back) /*gl.glTexCoord2f(1.0f, 0.0f); gl.glVertex3f(-1.0f, -1.0f, -1.0f); gl.glTexCoord2f(1.0f, 1.0f); gl.glVertex3f(-1.0f, 1.0f, -1.0f); gl.glTexCoord2f(0.0f, 1.0f); gl.glVertex3f( 1.0f, 1.0f, -1.0f); gl.glTexCoord2f(0.0f, 0.0f); gl.glVertex3f( 1.0f, -1.0f, -1.0f);*/ // Front Face //glColor3f (1.0f, 0.0f, 0.0f); // Set The Color To Red gl.glColor3f(0.0f, 0.4f, 0.0f); // Set The Color To Blue gl.glVertex3f(1.0f, 0.0f, 1.0f); // Top Right Of The Quad (Front) gl.glVertex3f( -1.0f, 0.0f, 1.0f); // Top Left Of The Quad (Front) gl.glVertex3f( -1.0f, -0.25f, 1.0f); // Bottom Left Of The Quad (Front) gl.glVertex3f(1.0f, -0.25f, 1.0f); // Bottom Right Of The Quad (Front) // Right face gl.glColor3f (0.0f, 0.4f, 0.0f); // Set The Color To Blue gl.glVertex3f (1.0f, 0.0f, -1.0f); // Top Right Of The Quad (Right) gl.glVertex3f (1.0f, 0.0f, 1.0f); // Top Left Of The Quad (Right) gl.glVertex3f (1.0f, -0.25f, 1.0f); // Bottom Left Of The Quad (Right) gl.glVertex3f (1.0f, -0.25f, -1.0f); // Bottom Right Of The Quad (Right) /*gl.glTexCoord2f(1.0f, 0.0f); gl.glVertex3f( 1.0f, -1.0f, -1.0f); gl.glTexCoord2f(1.0f, 1.0f); gl.glVertex3f( 1.0f, 1.0f, -1.0f); gl.glTexCoord2f(0.0f, 1.0f); gl.glVertex3f( 1.0f, 1.0f, 1.0f); gl.glTexCoord2f(0.0f, 0.0f); gl.glVertex3f( 1.0f, -1.0f, 1.0f);*/ // Left Face gl.glColor3f(0.0f, 0.4f, 0.0f); // Set The Color To Blue gl.glVertex3f( -1.0f, 0.0f, 1.0f); // Top Right Of The Quad (Left) gl.glVertex3f( -1.0f, 0.0f, -1.0f); // Top Left Of The Quad (Left) gl.glVertex3f( -1.0f, -0.25f, -1.0f); // Bottom Left Of The Quad (Left) gl.glVertex3f (-1.0f, -0.25f, 1.0f); // Bottom Right Of The Quad (Left) /*gl.glTexCoord2f(0.0f, 0.0f); gl.glVertex3f(-1.0f, -1.0f, -1.0f); gl.glTexCoord2f(1.0f, 0.0f); gl.glVertex3f(-1.0f, -1.0f, 1.0f); gl.glTexCoord2f(1.0f, 1.0f); gl.glVertex3f(-1.0f, 1.0f, 1.0f); gl.glTexCoord2f(0.0f, 1.0f); gl.glVertex3f(-1.0f, 1.0f, -1.0f); */ gl.glEnd(); xrot+=0.3f; yrot+=0.2f; zrot+=0.4f; }

/** Called when the display mode has been changed. <B>!! CURRENTLY
UNIMPLEMENTED IN JOGL !!</B>

  • @param gLDrawable The GLDrawable object.
  • @param modeChanged Indicates if the video mode has changed.
  • @param deviceChanged Indicates if the video device has changed.
    */
    public void displayChanged(GLDrawable gLDrawable, boolean modeChanged,
    boolean deviceChanged)
    {
    }

/** Called by the drawable immediately after the OpenGL context is

  • initialized for the first time. Can be used to perform one-time OpenGL
  • initialization such as setup of lights and display lists.
  • @param gLDrawable The GLDrawable object.
    */
    public void init(GLDrawable gLDrawable) { final GL gl = gLDrawable.getGL(); gl.glShadeModel(GL.GL_SMOOTH); // Enable Smooth Shading gl.glClearColor(0.0f, 0.0f, 0.0f, 0.5f); // Black Background gl.glClearDepth(1.0f); // Depth Buffer Setup gl.glEnable(GL.GL_DEPTH_TEST); // Enables Depth Testing gl.glDepthFunc(GL.GL_LEQUAL); // The Type Of Depth Testing To Do gl.glHint(GL.GL_PERSPECTIVE_CORRECTION_HINT, GL.GL_NICEST); // Really Nice Perspective Calculations gl.glEnable(GL.GL_TEXTURE_2D); gLDrawable.addKeyListener(this); texture[0] = genTexture(gl); gl.glBindTexture(GL.GL_TEXTURE_2D, texture[0]); BufferedImage img = readPNGImage("./tnetMSP.jpg"); makeRGBTexture(gl, gLDrawable.getGLU(), img, GL.GL_TEXTURE_2D, false); gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MIN_FILTER, GL.GL_LINEAR); gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MAG_FILTER, GL.GL_LINEAR); texture[1] = genTexture(gl); gl.glBindTexture(GL.GL_TEXTURE_2D, texture[1]); BufferedImage img2 = readPNGImage("./tnetRF.jpg"); makeRGBTexture(gl, gLDrawable.getGLU(), img2, GL.GL_TEXTURE_2D, false); gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MIN_FILTER, GL.GL_LINEAR); gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MAG_FILTER, GL.GL_LINEAR); }

/** Called by the drawable during the first repaint after the component has

  • been resized. The client can update the viewport and view volume of the
  • window appropriately, for example by a call to
  • GL.glViewport(int, int, int, int); note that for convenience the component
  • has already called GL.glViewport(int, int, int, int)(x, y, width, height)
  • when this method is called, so the client may not have to do anything in
  • this method.
  • @param gLDrawable The GLDrawable object.
  • @param x The X Coordinate of the viewport rectangle.
  • @param y The Y coordinate of the viewport rectanble.
  • @param width The new width of the window.
  • @param height The new height of the window.
    */
    public void reshape(GLDrawable gLDrawable, int x, int y, int width, int height) { final GL gl = gLDrawable.getGL(); final GLU glu = gLDrawable.getGLU(); if (height <= 0) // avoid a divide by zero error! height = 1; final float h = (float)width / (float)height; gl.glViewport(0, 0, width, height); gl.glMatrixMode(GL.GL_PROJECTION); gl.glLoadIdentity(); glu.gluPerspective(45.0f, h, 1.0, 20.0); gl.glMatrixMode(GL.GL_MODELVIEW); gl.glLoadIdentity(); }

/** Invoked when a key has been pressed.

  • See the class description for {@link KeyEvent} for a definition of
    * a key pressed event.
    * @param e The KeyEvent.
    */
    public void keyPressed(KeyEvent e)
    {}

    /** Invoked when a key has been released.
    * See the class description for {@link KeyEvent}

    for a definition of

  • a key released event.
  • @param e The KeyEvent.
    */
    public void keyReleased(KeyEvent e)
    {}

/** Invoked when a key has been typed.

  • See the class description for {@link KeyEvent}

    for a definition of

  • a key typed event.
  • @param e The KeyEvent.
    */
    public void keyTyped(KeyEvent e)
    Unknown macro: { if (e.getKeyChar() == KeyEvent.VK_ESCAPE) { System.exit(0); } }

private BufferedImage readPNGImage(String resourceName)
{
try
{
URL url = getResource(resourceName);
if (url == null)

{ throw new RuntimeException("Error reading resource " + resourceName); }

BufferedImage img = ImageIO.read(url);
java.awt.geom.AffineTransform tx =
java.awt.geom.AffineTransform.getScaleInstance(1, -1);
tx.translate(0, -img.getHeight(null));
AffineTransformOp op = new AffineTransformOp(tx,
AffineTransformOp.TYPE_NEAREST_NEIGHBOR);
img = op.filter(img, null);
return img;
}
catch (IOException e)

{ throw new RuntimeException(e); }

}

private void makeRGBTexture(GL gl, GLU glu, BufferedImage img, int target,
boolean mipmapped)
{
ByteBuffer dest = null;
switch (img.getType())
{
case BufferedImage.TYPE_3BYTE_BGR:
case BufferedImage.TYPE_CUSTOM:

{ byte[] data = ((DataBufferByte) img.getRaster().getDataBuffer()).getData (); dest = ByteBuffer.allocateDirect(data.length); dest.order(ByteOrder.nativeOrder()); dest.put(data, 0, data.length); break; }

case BufferedImage.TYPE_INT_RGB:

{ int[] data = ((DataBufferInt) img.getRaster().getDataBuffer()).getData(); dest = ByteBuffer.allocateDirect(data.length * BufferUtils.SIZEOF_INT); dest.order(ByteOrder.nativeOrder()); dest.asIntBuffer().put(data, 0, data.length); break; }

default:
throw new RuntimeException("Unsupported image type " + img.getType());
}

if (mipmapped)

{ glu.gluBuild2DMipmaps(target, GL.GL_RGB8, img.getWidth(), img.getHeight(), GL.GL_RGB, GL.GL_UNSIGNED_BYTE, dest); }

else

{ gl.glTexImage2D(target, 0, GL.GL_RGB, img.getWidth(), img.getHeight(), 0, GL.GL_RGB, GL.GL_UNSIGNED_BYTE, dest); }

}

private int genTexture(GL gl)

{ final int[] tmp = new int[1]; gl.glGenTextures(1, tmp); return tmp[0]; }

}

/** Retrieve a URL resource from the jar. If the resource is not found, then

  • the local disk is also checked.
  • @param filename Complete filename, including parent path
  • @return a URL object if resource is found, otherwise null.
    */
    public final static URL getResource(final String filename)
    {
    // Try to load resource from jar
    URL url = ClassLoader.getSystemResource(filename);
    // If not found in jar, then load from disk
    if (url == null)
    {
    try { url = new URL("file", "localhost", filename); }

    catch (Exception urlException){} // ignore
    }
    return url;
    }

/** Program's main entry point

  • @param args command line arguments.
    */
    public static void main(String[] args)
    {
    Frame frame = new Frame("Lesson 6: Texture Mapping");

JDesktopPane desktop=new JDesktopPane();
JInternalFrame l6frame = new JInternalFrame("3D texture", true,true,true,true);

l6frame.setBounds(0, 0, 400, 400);

GLCanvas canvas = GLDrawableFactory.getFactory().createGLCanvas(new
GLCapabilities());

canvas.addGLEventListener(new Renderer());
animator = new Animator(canvas);
l6frame.getContentPane().add(canvas);

desktop.add("Center",l6frame);

// frame.add(canvas);
frame.add(desktop);
frame.setSize(1024, 768);

frame.addWindowListener(new WindowAdapter()
{
public void windowClosing(WindowEvent e)

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

});

frame.show();
l6frame.setVisible(true);
animator.start();

}
}



 Comments   
Comment by moussaba [ 07/Aug/03 ]

Created an attachment (id=6)
Test Case for generating Exception with JinternalFrame

Comment by moussaba [ 07/Aug/03 ]

Created an attachment (id=7)
Test Case for generating Exception with JinternalFrame

Comment by moussaba [ 07/Aug/03 ]

Created an attachment (id=8)
Jar File for reproducing error

Comment by kbr [ 31/Jan/05 ]

Sorry for not investigating this bug until now. JOGL had proper
addNotify/removeNotify tracking added a while ago and the current JOGL source
runs the enclosed demo correctly. Please reopen this bug or file a new one if
you are still seeing problems.





[JOGL-23] glFinish() or glDeleteTextures() on Linux -> native crash Created: 04/Jul/03  Updated: 30/Apr/04  Resolved: 30/Apr/04

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

Type: Bug Priority: Blocker
Reporter: albanc 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: 23

 Description   

Calling glFinish(), glDeleteLists() or glDeleteTextures() with animator suspended on
Linux crashes on the native side (Nvidia Driver GeForce 4 MX440). The code runs
fine on windows :

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x4D31D428
Function=glFinish+0x0
Library=/usr/lib/libGL.so.1

Current Java thread:
at net.java.games.jogl.impl.x11.X11GLImpl.glFinish(Native Method)
at om.sceneElements.OmNode.cleanup(OmNode.java:506)
at om.sceneElements.OmScene.cleanup(OmScene.java:241)
at tools.viewer.objectLoaded(viewer.java:104)
at om.sceneToolkit.OmASEParser.notifyObjectLoaded
(OmASEParser.java:1135)
at om.sceneToolkit.OmASEParser.run(OmASEParser.java:208)

Dynamic libraries:
08048000-0804e000 r-xp 00000000 03:02
72299 /usr/local/share/j2sdk1.4.2/bin/java
0804e000-0804f000 rw-p 00005000 03:02
72299 /usr/local/share/j2sdk1.4.2/bin/java
40000000-40011000 r-xp 00000000 03:02 47230 /lib/ld-2.3.1.so
40011000-40012000 rw-p 00011000 03:02 47230 /lib/ld-2.3.1.so
40012000-4001a000 r-xp 00000000 03:02
71679 /usr/local/share/j2sdk1.4.2/jre/lib/i386/native_threads/libhpi.so
4001a000-4001b000 rw-p 00007000 03:02
71679 /usr/local/share/j2sdk1.4.2/jre/lib/i386/native_threads/libhpi.so
4001c000-40028000 r-xp 00000000 03:02 47248 /lib/libpthread-0.10.so
40028000-4002b000 rw-p 0000c000 03:02 47248 /lib/libpthread-0.10.so
4006b000-4006d000 r-xp 00000000 03:02 47235 /lib/libdl-2.3.1.so
4006d000-4006e000 rw-p 00001000 03:02 47235 /lib/libdl-2.3.1.so
4006e000-40176000 r-xp 00000000 03:02 47233 /lib/libc-2.3.1.so
40176000-4017c000 rw-p 00107000 03:02 47233 /lib/libc-2.3.1.so
4017e000-40573000 r-xp 00000000 03:02
71685 /usr/local/share/j2sdk1.4.2/jre/lib/i386/client/libjvm.so
40573000-4058f000 rw-p 003f4000 03:02
71685 /usr/local/share/j2sdk1.4.2/jre/lib/i386/client/libjvm.so
405a1000-405b1000 r-xp 00000000 03:02 47237 /lib/libnsl-2.3.1.so
405b1000-405b2000 rw-p 00010000 03:02 47237 /lib/libnsl-2.3.1.so
405b4000-405d4000 r-xp 00000000 03:02 47236 /lib/libm-2.3.1.so
405d4000-405d5000 rw-p 0001f000 03:02 47236 /lib/libm-2.3.1.so
405d5000-405d9000 rw-s 00000000 03:02 57021 /tmp/hsperfdata_ace/849
405d9000-405dc000 r--s 00000000 03:02
71717 /usr/local/share/j2sdk1.4.2/jre/lib/ext/dnsns.jar
405dc000-405dd000 r-xp 00000000 03:02
71710 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libjawt.so
405dd000-405de000 rw-p 00000000 03:02
71710 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libjawt.so
405de000-405e7000 r-xp 00000000 03:02 47238 /lib/libnss_compat-2.3.1.so
405e7000-405e8000 rw-p 00009000 03:02 47238 /lib/libnss_compat-2.3.1.so
405e8000-405f8000 r-xp 00000000 03:02
71690 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libverify.so
405f8000-405fa000 rw-p 0000f000 03:02
71690 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libverify.so
405fa000-4061a000 r-xp 00000000 03:02
71691 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libjava.so
4061a000-4061c000 rw-p 0001f000 03:02
71691 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libjava.so
4061c000-40630000 r-xp 00000000 03:02
71693 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libzip.so
40630000-40633000 rw-p 00013000 03:02
71693 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libzip.so
40633000-41fb6000 r--s 00000000 03:02
72241 /usr/local/share/j2sdk1.4.2/jre/lib/rt.jar
42000000-42016000 r--s 00000000 03:02
71720 /usr/local/share/j2sdk1.4.2/jre/lib/sunrsasign.jar
42016000-420f0000 r--s 00000000 03:02
72201 /usr/local/share/j2sdk1.4.2/jre/lib/jsse.jar
420f0000-42101000 r--s 00000000 03:02
71721 /usr/local/share/j2sdk1.4.2/jre/lib/jce.jar
42101000-4265a000 r--s 00000000 03:02
72239 /usr/local/share/j2sdk1.4.2/jre/lib/charsets.jar
44702000-4470f000 r--s 00000000 03:02
71718 /usr/local/share/j2sdk1.4.2/jre/lib/ext/ldapsec.jar
4470f000-44710000 rw-s 40000000 03:02 5090 /dev/nvidia0
4c790000-4c7df000 r--p 00000000 03:02 56868 /usr/lib/locale/locale-archive
4c7df000-4c7fb000 r--s 00000000 03:02
71716 /usr/local/share/j2sdk1.4.2/jre/lib/ext/sunjce_provider.jar
4c7fb000-4c8b7000 r--s 00000000 03:02
71719 /usr/local/share/j2sdk1.4.2/jre/lib/ext/localedata.jar
4c8b7000-4c8dd000 r-s 00000000 00:08 8945708 /home/ace/openmind
jsr/binary-distribution/lib/openmind-core.jar
4c8dd000-4c8f9000 r-s 00000000 00:08 8945707 /home/ace/openmind
jsr/binary-distribution/lib/vecmath-free.jar
4c8f9000-4c9bb000 r-s 00000000 00:08 8945706 /home/ace/openmind
jsr/binary-distribution/lib/jogl.jar
4c9bb000-4cc86000 r-xp 00000000 03:02
71701 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libawt.so
4cc86000-4cc9b000 rw-p 002ca000 03:02
71701 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libawt.so
4ccc1000-4cd14000 r-xp 00000000 03:02
71700 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libmlib_image.so
4cd14000-4cd15000 rw-p 00052000 03:02
71700 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libmlib_image.so
4cd15000-4cd1b000 r-s 00000000 00:08 8945704 /home/ace/openmind
jsr/binary-distribution/lib/joal.jar
4cd1b000-4cd1d000 r-xp 00000000 03:02
35383 /usr/X11R6/lib/X11/locale/common/xlcDef.so.2
4cd1d000-4cd1e000 rw-p 00001000 03:02
35383 /usr/X11R6/lib/X11/locale/common/xlcDef.so.2
4cd1e000-4cd24000 r-xp 00000000 03:02 35682 /usr/X11R6/lib/libXp.so.6.2
4cd24000-4cd25000 rw-p 00006000 03:02 35682 /usr/X11R6/lib/libXp.so.6.2
4cd25000-4cd6b000 r-xp 00000000 03:02 35513 /usr/X11R6/lib/libXt.so.6.0
4cd6b000-4cd6f000 rw-p 00045000 03:02 35513 /usr/X11R6/lib/libXt.so.6.0
4cd6f000-4cd7b000 r-xp 00000000 03:02 35512 /usr/X11R6/lib/libXext.so.6.4
4cd7b000-4cd7c000 rw-p 0000c000 03:02 35512 /usr/X11R6/lib/libXext.so.6.4
4cd7c000-4cd80000 r-xp 00000000 03:02 35508 /usr/X11R6/lib/libXtst.so.6.1
4cd80000-4cd81000 rw-p 00003000 03:02 35508 /usr/X11R6/lib/libXtst.so.6.1
4cd81000-4ce38000 r-xp 00000000 03:02 35676 /usr/X11R6/lib/libX11.so.6.2
4ce38000-4ce3b000 rw-p 000b7000 03:02 35676 /usr/X11R6/lib/libX11.so.6.2
4ce3b000-4ce42000 r-xp 00000000 03:02 35681 /usr/X11R6/lib/libSM.so.6.0
4ce42000-4ce43000 rw-p 00007000 03:02 35681 /usr/X11R6/lib/libSM.so.6.0
4ce43000-4ce56000 r-xp 00000000 03:02 35509 /usr/X11R6/lib/libICE.so.6.3
4ce56000-4ce58000 rw-p 00012000 03:02 35509 /usr/X11R6/lib/libICE.so.6.3
4ce59000-4ce67000 r-s 00000000 00:08 8945701 /home/ace/openmind
jsr/binary-distribution/lib/png.jar
4ce67000-4cf1c000 r--s 00000000 00:08 11812873 /home/ace/bin/ant/lib/ant.jar
4cf1c000-4cf37000 r-s 00000000 00:08 11812874 /home/ace/bin/ant/lib/xml
apis.jar
4cf37000-4d010000 r--s 00000000 00:08
11812875 /home/ace/bin/ant/lib/xercesImpl.jar
4d010000-4d0b4000 r--s 00000000 00:08
11812872 /home/ace/bin/ant/lib/optional.jar
4d0b4000-4d125000 r--s 00000000 00:08
7127087 /home/ace/Jimi/examples/AppletDemo/JimiProClasses.jar
4d125000-4d1df000 r-xp 00000000 03:02
71704 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libfontmanager.so
4d1df000-4d1f9000 rw-p 000b9000 03:02
71704 /usr/local/share/j2sdk1.4.2/jre/lib/i386/libfontmanager.so
4d1fa000-4d214000 r-xp 00000000 03:02
35381 /usr/X11R6/lib/X11/locale/common/ximcp.so.2
4d214000-4d216000 rw-p 00019000 03:02
35381 /usr/X11R6/lib/X11/locale/common/ximcp.so.2
4d216000-4d218000 r-xp 00000000 03:02 47387 /usr/lib/gconv/ISO8859-15.so
4d218000-4d219000 rw-p 00001000 03:02 47387 /usr/lib/gconv/ISO8859-15.so
4d219000-4d2dc000 r-xp 00000000 00:08 8945705 /home/ace/openmind-
jsr/binary-distribution/lib/libjogl.so
4d2dc000-4d2de000 rw-p 000c2000 00:08 8945705 /home/ace/openmind-
jsr/binary-distribution/lib/libjogl.so
4d2de000-4d2df000 rwxp 00000000 03:02 3311 /dev/zero
4d2df000-4d2e0000 rwxp 00000000 03:02 3311 /dev/zero
4d2e0000-4d2e1000 rwxp 00000000 03:02 3311 /dev/zero
4d2e1000-4d2e2000 rwxp 00000000 03:02 3311 /dev/zero
4d2e2000-4d2e3000 rwxp 00000000 03:02 3311 /dev/zero
4d2e3000-4d2e4000 rwxp 00000000 03:02 3311 /dev/zero
4d2e4000-4d2e5000 rwxp 00000000 03:02 3311 /dev/zero
4d2e5000-4d2e6000 rwxp 00000000 03:02 3311 /dev/zero
4d2e6000-4d2e7000 rwxp 00000000 03:02 3311 /dev/zero
4d2e7000-4d32a000 r-xp 00000000 03:02 8702 /usr/lib/libGL.so.1.0.3123
4d32a000-4d32d000 rw-p 00042000 03:02 8702 /usr/lib/libGL.so.1.0.3123
4d32f000-4d398000 r-xp 00000000 03:02 56459 /usr/X11R6/lib/libGLU.so.1.3
4d398000-4d3a2000 rw-p 00069000 03:02 56459 /usr/X11R6/lib/libGLU.so.1.3
4d3a2000-4d70a000 r-xp 00000000 03:02 10330 /usr/lib/libGLcore.so.1.0.3123
4d70a000-4d712000 rw-p 00367000 03:02 10330 /usr/lib/libGLcore.so.1.0.3123
4d73c000-4d7cc000 r-xp 00000000 03:02 10392 /usr/lib/libstdc++.so.5.0.4
4d7cc000-4d7e3000 rw-p 0008f000 03:02 10392 /usr/lib/libstdc++.so.5.0.4
4d7e8000-4d7ee000 r-xp 00000000 03:02 10366 /lib/libgcc_s.so.1
4d7ee000-4d7ef000 rw-p 00006000 03:02 10366 /lib/libgcc_s.so.1
4d8e9000-4d9f0000 rw-s 00000000 00:04 0 /SYSV00000000 (deleted)
4d9f0000-559f0000 rw-s 10000000 03:02 5090 /dev/nvidia0
55aaf000-55bb1000 rw-s 80000000 03:02 5090 /dev/nvidia0
55bb1000-55bc1000 rw-s 00810000 03:02 5090 /dev/nvidia0
55de3000-55ee5000 rw-s 80000000 03:02 5090 /dev/nvidia0
55ee5000-55ef5000 rw-s 00820000 03:02 5090 /dev/nvidia0
55ff7000-55ff8000 rw-s 40000000 03:02 5090 /dev/nvidia0

Heap at VM Abort:
Heap
def new generation total 576K, used 208K [0x44710000, 0x447b0000,
0x44bf0000)
eden space 512K, 34% used [0x44710000, 0x4473cc58, 0x44790000)
from space 64K, 45% used [0x447a0000, 0x447a7578, 0x447b0000)
to space 64K, 0% used [0x44790000, 0x44790000, 0x447a0000)
tenured generation total 1648K, used 1163K [0x44bf0000, 0x44d8c000,
0x48710000)
the space 1648K, 70% used [0x44bf0000, 0x44d12dc8, 0x44d12e00,
0x44d8c000)
compacting perm gen total 4864K, used 4851K [0x48710000, 0x48bd0000,
0x4c710000)
the space 4864K, 99% used [0x48710000, 0x48bcced8, 0x48bcd000,
0x48bd0000)

Local Time = Fri Jul 4 16:51:34 2003
Elapsed Time = 2
#

  1. The exception above was detected in native code outside the VM
    #
  2. Java VM: Java HotSpot(TM) Client VM (1.4.2-beta-b19 mixed mode)
    #


 Comments   
Comment by kbr [ 14/Jul/03 ]

Please submit a boiled-down test case. I'm aware that your application does some
fancy context handling and I think most probably you are calling OpenGL routines
without a current context, which can lead to driver crashes.

Comment by kbr [ 30/Apr/04 ]

Please retest with the JOGL 1.1 builds and either reopen this issue or file a
new one if there are still problems. Again, I believe these errors are caused by
application code and not JOGL's core code.





[JOGL-21] Cannot build mac OSX version of JoGL with files from the cvs Created: 03/Jul/03  Updated: 14/Jul/03  Resolved: 14/Jul/03

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

Type: Bug Priority: Blocker
Reporter: albanc 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


Issuezilla Id: 21

 Description   

It looks like the file JAWT_MacOSXDrawingSurfaceInfo from the CVS has not been
updated. it does not define method cocoaViewRef() and compilation fails on MacOSX:

../src/net/java/games/jogl/impl/macosx/MacOSXOnscreenGLContext.java:233: cannot
resolve symbol
symbol : method cocoaViewRef ()
location: class net.java.games.jogl.impl.macosx.JAWT_MacOSXDrawingSurfaceInfo
nsView = macosxdsi.cocoaViewRef();
^
Note: ../src/net/java/games/jogl/GLCanvas.java uses or overrides a deprecated API.
Note: Recompile with -deprecation for details.
1 error
make[1]: *** [../build/classes/net/java/games/jogl/Animator.class] Error 1
make: [macosx] Error 2 (ignored)



 Comments   
Comment by kbr [ 14/Jul/03 ]

The Mac OS X port of Jogl requires and will require 10.3, which is currently
only available as Developer Preview 1. There is no way to make Jogl work with
10.2 or earlier.





[JOGL-20] Prebult Binaries are a must-have Created: 02/Jul/03  Updated: 14/Jul/03  Resolved: 14/Jul/03

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

Type: Bug Priority: Blocker
Reporter: kaffiene 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: 20

 Description   

We must have prebuilt binaries available. The current situation (having to
build the code) limits the audience for Jogl.

Obviously, quite a few people do not have Visual C++, for example.



 Comments   
Comment by kbr [ 14/Jul/03 ]

Binaries are now available.





[JOGL-9] ANT script for compile sources Created: 17/Jun/03  Updated: 23/Jun/03  Resolved: 23/Jun/03

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

Type: Improvement Priority: Blocker
Reporter: wiederke 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


Issuezilla Id: 9

 Description   

Using ANT to compile sources instead of make.



 Comments   
Comment by djp [ 23/Jun/03 ]

This is the same request as issue #2. Will close as a duplicate.

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




[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-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-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-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-284] JOGL does not paint when window size==display size and not window.isActive Created: 27/Feb/07  Updated: 02/Mar/07  Resolved: 02/Mar/07

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

Type: Bug Priority: Blocker
Reporter: jesmith Assignee: jogl-issues
Resolution: Cannot Reproduce 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 Gears.java    
Issuezilla Id: 284

 Description   

When the JOGL GLCanvas is in an undecorated Frame (AWT), which is the same size as the screen, it
does not paint when the Frame is not Active (that is, when it is in the background, and other
WindowsXP application windows overlap it).

If the Frame is not exactly the same size as the screen, such as being +/- 1 pixel different in width,
then Alt-Tab'ing to another application leaves a correctly painting JOGL window in the background. It
appears that there is some "exact match" logic somewhere in the JOGL source, although my searches
turned up no obvious candidates.

I believe this problem started when I switched from JDK 1.4.2 to JDK 1.6. It exists in 1.1.0 RC3 and
1.0.0.

This would not be a problem with full-screen-exclusive windows, since they cannot be in the
background. Rather, it is only a problem for full-screen, non-exclusive windows.

I am seeing this with NVIDIA Quadro FX 3500 and 4500 cards. I have not tried to reproduce on an ATI
system.



 Comments   
Comment by jesmith [ 27/Feb/07 ]

I meant to make this P1 when I submitted it.

Comment by jesmith [ 27/Feb/07 ]

Created an attachment (id=94)
Test case

Comment by jesmith [ 27/Feb/07 ]

I've attached a simple test case, which is the Gears demo with a couple extra lines.

Note that in creating this test case, I discovered that there is another key factor: Antialiasing. This
problem does not occur when FSAA is 0. Therefore I now suspect this is really an NVIDIA bug, not a JOGL
bug. Although it's profoundly weird that it did not happen when we used Java 1.4, and it does happen
now, with no NVIDIA driver upgrades in between....

Comment by kbr [ 27/Feb/07 ]

Are you specifying -Dsun.java2d.noddraw=true on the command line? This is
required for guaranteed correct operation of all JOGL applications on Windows.

Comment by jesmith [ 28/Feb/07 ]

Yes, the test case is reproduced with -Dsun.java2d.noddraw=true, and also with -
Dsun.java2d.opengl=true (in any combination)

This is clearly not an interaction with AWT since, it happens when you alt-Tab to a completely different
application as well. And, keep in mind, that it only happens with antialiasing On.

My bet now is that this is actually an NVIDIA bug, where they are assuming that a fullscreen window is a
fullscreen exclusive window (by testing the window size, but not testing for exclusivity), and doing some
inappropriate optimizations for that case.

As such, you might just want to close this bug. Since I now no longer believe it's JOGL's fault.

Comment by kbr [ 02/Mar/07 ]

As indicated by the submitter, this is almost certainly not a JOGL bug. Closing
as "works for me".





[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-253] Provide binaries for Windows Vista x64 Created: 30/Nov/06  Updated: 30/Dec/06  Resolved: 30/Dec/06

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

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

Operating System: Windows XP
Platform: All


Issuezilla Id: 253

 Description   

Windows Vista x64 will be available in 1Q 2007. Binaries would be helpful for
users who do not own the prerequisite compilers for building JOGL from source.



 Comments   
Comment by kbr [ 01/Dec/06 ]

We'll add Windows x64 binaries as soon as we have hardware available.

Comment by kbr [ 30/Dec/06 ]

Windows x64 binaries have been added to the nightly builds, the most recent
release build, and the web start binaries.





[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-203] Missing setup of GL_UNPACK_ALIGNMENT for mipmapped images in TextureIO Created: 09/Feb/06  Updated: 09/Feb/06  Resolved: 09/Feb/06

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

Type: Bug Priority: Critical
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


Attachments: GIF File TotsLogo.gif     Java Source File TotsTest.java    
Issuezilla Id: 203

 Description   

The attached small test case and gif show continued problems with
non-power-of-two textures and the Java port of the GLU mipmap routines.



 Comments   
Comment by kbr [ 09/Feb/06 ]

Created an attachment (id=72)
gif for test case

Comment by kbr [ 09/Feb/06 ]

Created an attachment (id=73)
Test case

Comment by kbr [ 09/Feb/06 ]

It turns out this was simply a missing setup of the GL_UNPACK_ALIGNMENT in the
TextureIO utility class in the case where mipmaps were being generated. The
mipmap generation code appears to be fine for this case.





[JOGL-197] Create projects page Created: 25/Jan/06  Updated: 24/Nov/06  Resolved: 24/Nov/06

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

Type: Improvement Priority: Critical
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: 197

 Description   

A page or set of pages linking to the projects using JOGL is sorely needed. Some
links for the initial set of projects to add:

Put together web page of projects which use JOGL

Jake2, Agency9
http://processing.org/
http://today.java.net/pub/a/today/2005/08/16/earth.html
FengGUI: http://www.javagaming.org/forums/index.php?topic=12116.0



 Comments   
Comment by kbr [ 19/Nov/06 ]

More projects:
GLStudio
Art of Illusion
chronotext.org
Jack Flowers

Comment by kbr [ 24/Nov/06 ]

Several featured projects have been listed on the JOGL home page. While the list
is certainly incomplete, it is a start and the HTML framework is there for
adding more. Finally closing this RFE as fixed.





[JOGL-152] Exception in Native Code while forcing all work onto the AWT event queue thread Created: 31/Mar/05  Updated: 06/May/05  Resolved: 06/May/05

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

Type: Bug Priority: Critical
Reporter: styles 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: PC


Issuezilla Id: 152

 Description   

OS: WindowsXP Professional w/ SP2
CPU: Intel P4 2.66GHz
Vid Card: Intel onboard 82865G
Driver: latest version 6.14.10.4277

All previous versions of JOGL have run these demos just fine. Just with the
latest version 1.1b10 I encounter an exception in the native code. Examining the
stack trace, it fails during a call in my code to gl.glGenTextures().
If specifying -Djogl.1thread=false on the command line, the app then runs as
expected without error.

Below is the dump:

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x36F145B
Function=[Unknown.]
Library=C:\WINDOWS\system32\ialmgicd.dll

NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.

Current Java thread:
at net.java.games.jogl.impl.windows.WindowsGLImpl.glGenTextures(Native Method)
at Lesson18.initCustom(Lesson18.java:172)
at Renderer.init(Renderer.java:213)
at net.java.games.jogl.impl.GLDrawableHelper.init(GLDrawableHelper.java:68)
at net.java.games.jogl.GLCanvas$InitAction.run(GLCanvas.java:234)
at
net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:171)

  • locked <0x10091180> (a net.java.games.jogl.impl.windows.WindowsOnscreenGLContext)
    at
    net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:129)
  • locked <0x10091180> (a net.java.games.jogl.impl.windows.WindowsOnscreenGLContext)
    at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:246)
  • locked <0x10091180> (a net.java.games.jogl.impl.windows.WindowsOnscreenGLContext)
    at
    net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.invokeGL(WindowsOnscreenGLContext.java:76)
  • locked <0x105b2f40> (a java.awt.Component$AWTTreeLock)
    at net.java.games.jogl.GLCanvas$2.run(GLCanvas.java:122)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
    at
    java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
    at
    java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

Dynamic libraries:
0x00400000 - 0x0040B000 C:\j2sdk1.4.2_05\jre\bin\javaw.exe
0x7C900000 - 0x7C9B0000 C:\WINDOWS\system32\ntdll.dll
0x7C800000 - 0x7C8F4000 C:\WINDOWS\system32\kernel32.dll
0x77DD0000 - 0x77E6B000 C:\WINDOWS\system32\ADVAPI32.dll
0x77E70000 - 0x77F01000 C:\WINDOWS\system32\RPCRT4.dll
0x77D40000 - 0x77DD0000 C:\WINDOWS\system32\USER32.dll
0x77F10000 - 0x77F56000 C:\WINDOWS\system32\GDI32.dll
0x77C10000 - 0x77C68000 C:\WINDOWS\system32\MSVCRT.dll
0x08000000 - 0x08139000 C:\j2sdk1.4.2_05\jre\bin\client\jvm.dll
0x76B40000 - 0x76B6D000 C:\WINDOWS\system32\WINMM.dll
0x10000000 - 0x10007000 C:\j2sdk1.4.2_05\jre\bin\hpi.dll
0x00830000 - 0x0083E000 C:\j2sdk1.4.2_05\jre\bin\verify.dll
0x00840000 - 0x00859000 C:\j2sdk1.4.2_05\jre\bin\java.dll
0x00860000 - 0x0086D000 C:\j2sdk1.4.2_05\jre\bin\zip.dll
0x02E50000 - 0x02F62000 C:\j2sdk1.4.2_05\jre\bin\awt.dll
0x73000000 - 0x73026000 C:\WINDOWS\system32\WINSPOOL.DRV
0x76390000 - 0x763AD000 C:\WINDOWS\system32\IMM32.dll
0x774E0000 - 0x7761D000 C:\WINDOWS\system32\ole32.dll
0x5AD70000 - 0x5ADA8000 C:\WINDOWS\system32\uxtheme.dll
0x02FE0000 - 0x03031000 C:\j2sdk1.4.2_05\jre\bin\fontmanager.dll
0x73760000 - 0x737A9000 C:\WINDOWS\system32\ddraw.dll
0x73BC0000 - 0x73BC6000 C:\WINDOWS\system32\DCIMAN32.dll
0x73940000 - 0x73A10000 C:\WINDOWS\system32\D3DIM700.DLL
0x74720000 - 0x7476B000 C:\WINDOWS\system32\MSCTF.dll
0x77120000 - 0x771AC000 C:\WINDOWS\system32\OLEAUT32.DLL
0x031A0000 - 0x031A5000 C:\j2sdk1.4.2_05\jre\bin\jawt.dll
0x03230000 - 0x03290000 C:\WINDOWS\system32\jogl.dll
0x5ED00000 - 0x5EDCC000 C:\WINDOWS\system32\OPENGL32.dll
0x68B20000 - 0x68B40000 C:\WINDOWS\system32\GLU32.dll
0x036E0000 - 0x03913000 C:\WINDOWS\system32\ialmgicd.dll
0x039C0000 - 0x03A40000 C:\WINDOWS\system32\ialmgdev.dll
0x76C90000 - 0x76CB8000 C:\WINDOWS\system32\imagehlp.dll
0x59A60000 - 0x59B01000 C:\WINDOWS\system32\DBGHELP.dll
0x77C00000 - 0x77C08000 C:\WINDOWS\system32\VERSION.dll
0x76BF0000 - 0x76BFB000 C:\WINDOWS\system32\PSAPI.DLL

Heap at VM Abort:
Heap
def new generation total 576K, used 130K [0x10010000, 0x100b0000, 0x104f0000)
eden space 512K, 13% used [0x10010000, 0x10020a58, 0x10090000)
from space 64K, 100% used [0x10090000, 0x100a0000, 0x100a0000)
to space 64K, 0% used [0x100a0000, 0x100a0000, 0x100b0000)
tenured generation total 1408K, used 1077K [0x104f0000, 0x10650000, 0x14010000)
the space 1408K, 76% used [0x104f0000, 0x105fd568, 0x105fd600, 0x10650000)
compacting perm gen total 6656K, used 6514K [0x14010000, 0x14690000, 0x18010000)
the space 6656K, 97% used [0x14010000, 0x1466cbd8, 0x1466cc00, 0x14690000)

Local Time = Thu Mar 31 10:16:38 2005
Elapsed Time = 4
#

  1. The exception above was detected in native code outside the VM
    #
  2. Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode)
    #


 Comments   
Comment by kbr [ 06/May/05 ]

I believe the submitter indicated on the forums that this was caused by calling
glBindTexture(-1), leading to a driver crash later. Please file a new bug and
attach a test case if the problem persists. The DebugGL pipeline can help track
down these kinds of problems very quickly.





[JOGL-149] Swing GLPanel fails with "unexpected async reply" while AWT GLCanvas works Created: 22/Mar/05  Updated: 12/May/05  Resolved: 12/May/05

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

Type: Bug Priority: Critical
Reporter: ac378_ 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


Issuezilla Id: 149

 Description   

First my environment:

  • hardware:
  • /cpu/cpuinfo = AMD Athlon XP 2200+
  • lspci = ATI R300 ND [Radeon 9700 Pro]
  • software
  • mdk 10
  • uname -sr = Linux 2.6.3-7mdk-i686-up-4GB
  • java -version =
    java version "1.4.2_07"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05)
    Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode)
  • jogl = 1.1b10 - February 27
  • XFree86 = 4.3.0.1
  • glxinfo =
    name of display: :0.0
    display: :0 screen: 0
    direct rendering: No
    server glx vendor string: SGI
    server glx version string: 1.2
    server glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
    client glx vendor string: ATI
    client glx version string: 1.3
    client glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context,
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_ATI_pixel_format_float,
    GLX_ATI_render_texture
    GLX extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
    OpenGL vendor string: Mesa project: www.mesa3d.org
    OpenGL renderer string: Mesa GLX Indirect
    OpenGL version string: 1.3 Mesa 4.0.4
    OpenGL extensions:
    GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp,
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
    GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3,
    GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color,
    GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_env_add,
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
    GL_EXT_texture_lod_bias
    glu version: 1.3
    glu extensions:
    GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

So when i try the demos (from jogl, same version):

  • demos.gears.Gears: OK

CANVAS GL IS: net.java.games.jogl.impl.x11.X11GLImpl
CANVAS GLU IS: net.java.games.jogl.impl.GLUImpl
INIT GL IS: net.java.games.jogl.impl.x11.X11GLImpl
GL_VENDOR: Mesa project: www.mesa3d.org
GL_RENDERER: Mesa GLX Indirect
GL_VERSION: 1.3 Mesa 4.0.4

glLoadTransposeMatrixfARB() supported: true

  • demos.jgears.JGears: app freeze

DRAWABLE GL IS: net.java.games.jogl.impl.x11.X11GLImpl
DRAWABLE GLU IS: net.java.games.jogl.impl.GLUImpl
Xlib: unexpected async reply (sequence 0x1c9)! *****************
INIT GL IS: net.java.games.jogl.impl.x11.X11GLImpl
GL_VENDOR: Mesa project: www.mesa3d.org
GL_RENDERER: Mesa GLX Indirect
GL_VERSION: 1.3 Mesa 4.0.4

zsh: suspended ./start-demo.sh
$ kill -9 %1

You already have the source code of the demos.



 Comments   
Comment by kbr [ 12/May/05 ]

I don't have a Linux ATI machine available to test with (the newest ATI drivers
don't work on my machine, and I lost my ancient copy of their working drivers).
All of the demos are working correctly on Solaris/x86 and Linux/x86 with NVidia
drivers. Please retest with JOGL 1.1 b11, which has some more AWT locking code
around GLX calls, and reopen the bug if it is still present.





[JOGL-151] starting up the Animator before the GLJPanel has been shown result in an error Created: 27/Mar/05  Updated: 06/May/05  Resolved: 06/May/05

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

Type: Bug Priority: Critical
Reporter: bwaant 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


Attachments: Zip Archive speeltuin-modified.zip     Text File speeltuin.zip    
Issuezilla Id: 151

 Description   

This error only happend with the newest Geforce videoboards.



 Comments   
Comment by bwaant [ 27/Mar/05 ]

Created an attachment (id=40)
demo project

Comment by bwaant [ 27/Mar/05 ]

replacing the lines: final Animator animator = new Animator(canvas);
animator.start(); into the methode SetGebouwData() it works fine. So the
place (not in de constructor) of initiating the animator is crucial

Comment by kbr [ 06/May/05 ]

Created an attachment (id=49)
Version of test case which now works properly

Comment by kbr [ 06/May/05 ]

The root cause of this error was the fact that
WindowsPbufferGLContext.destroyImpl() uses WGL extensions to clean up
resources associated with the pbuffer. Because these extensions are in
the public WGL interface, they are wrapped by the DebugGL. However, an
OpenGL context is not current at the time these routines are called,
and it is illegal to call glGetError() at those points. The DebugGL
pipeline was implicitly calling glGetError() after each of those
calls, leading to the failure.

This bug unmasked a couple of others. The code in the DebugGL needed a
recursion count to make sure that glGetError() didn't get called in an
infinite loop. Also, as a side effect of the fix for Issue 160,
calling getGL() on the GLJPanel outside of GLEventListener.init() was
causing a NullPointerException to be thrown. The GLJPanel has been
fixed to return null in this case, and the specification of
GLDrawable.getGL() has been improved. In order to make the behavior
between the GLCanvas and GLJPanel similar, the GL object is now reset
in the GLDrawable each time the underlying OpenGL context is
recreated. This allows end users to set up e.g. the DebugGL
unconditionally in their GLEventListener.init() method. The JOGL demos
have been changed to reflect this.

The test case has been updated with code similar to the originally
submitted test case (i.e., the Animator is started early) but which
now works.





[JOGL-145] Clipping panes cause garbage display Created: 01/Mar/05  Updated: 13/Apr/05  Resolved: 13/Apr/05

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

Type: Bug Priority: Critical
Reporter: gusgus84 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: Mac OS X
Platform: Macintosh


Issuezilla Id: 145

 Description   

-Using a PowerBook G4 with an ATI 9800XT, up to date with Software Update

-Runnning the following program:
http://www.chem.byu.edu/Plone/people/rbshirts/research/Boltzmann3D.dmg

When set to 3D mode (Simulation menu>Dimension->3 Dimensions), the clipping
panes set just outside the walls cause them to only be partially rendered.

Here's a basic gist of what's going on in the code (works fine on Mac with
Nvidia and ALL PC's I've tried it on).

double clipDistance=1.0d;
double w=getSize().width, h=getSize().height, d=curZSize;
double w2=w/2, h2=h/2, d2=d/2;
//Look at the center of the box
myGLU.gluLookAt(w2,h2, camz,
w2,h2, 0,
0, 1, 0);
//Rotate the box to make it look like the camera is moving
myGL.glTranslated(w2,h2,d2);
myGL.glRotatef((float)GUIGlobal.camAngleY,0,1, 0);
double angle=camAngleY*Math.PI/180;
myGL.glRotatef((float)camAngleX,(float)Math.cos(angle),0, (float)Math.sin
(angle));
myGL.glTranslated(-w2,-h2,-d2);
//Set clipping planes to be just outside of the box
myGL.glClipPlane(GL.GL_CLIP_PLANE0,new double[]

{1,0,0,clipDistance}

);
myGL.glClipPlane(GL.GL_CLIP_PLANE2,new double[]

{0,1,0,clipDistance}

);
myGL.glClipPlane(GL.GL_CLIP_PLANE4,new double[]

{0,0,1,clipDistance}

);
myGL.glRotatef(180,0,1,0);
myGL.glClipPlane(GL.GL_CLIP_PLANE1,new double[]

{1,0,0,w+clipDistance}

);
myGL.glClipPlane(GL.GL_CLIP_PLANE5,new double[]

{0,0,1,d+clipDistance}

);
myGL.glRotatef(-180,0,1,0);
myGL.glRotatef(180,1,0,0);
myGL.glClipPlane(GL.GL_CLIP_PLANE3,new double[]

{0,1,0,h+clipDistance}

);
myGL.glRotatef(-180,1,0,0);



 Comments   
Comment by gusgus84 [ 01/Mar/05 ]

Correction: It was a Radeon 9600, NOT 9800

Comment by kbr [ 02/Mar/05 ]

This is highly unlikely to be a bug in JOGL, but rather in your vendor's OpenGL
drivers. I would suggest trying JOGL 1.1 b10 and if the problem persists then
file a bug with Apple. You might want to try on a Windows machine with an ATI
card as well and if the problem occurs there then file a bug with ATI using
their web feedback form.

Comment by kbr [ 09/Apr/05 ]

Have you tested with JOGL 1.1 b10, and does it change the behavior?

Comment by kbr [ 13/Apr/05 ]

The submitter has indicated that the problem is also reproducible with a C++
program, so it is likely to be a bug in the drivers rather than in JOGL. Closing
this as "works for me".





[JOGL-142] REGRESSION Error making context current in b09 Created: 18/Feb/05  Updated: 11/Jan/06  Resolved: 11/Jan/06

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

Type: Bug Priority: Critical
Reporter: gusgus84 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: All


Issuezilla Id: 142

 Description   

This program was tested and worked properly using b07, but upgrading to b09
causes the following exception:

net.java.games.jogl.GLException: Error making context current
at
net.java.games.jogl.impl.x11.X11GLContext.makeCurrent(X11GLContext.java:173)
at
net.java.games.jogl.impl.x11.X11OnscreenGLContext.makeCurrent(X11OnscreenGLContext.java:111)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:246)
at
net.java.games.jogl.GLCanvas.withSingleThreadedWorkaroundDo(GLCanvas.java:228)
at net.java.games.jogl.GLCanvas.reshape(GLCanvas.java:125)
at java.awt.Component.setBounds(Component.java:1664)
at java.awt.BorderLayout.layoutContainer(BorderLayout.java:691)
at java.awt.Container.layout(Container.java:1020)
at java.awt.Container.doLayout(Container.java:1010)
at java.awt.Container.validateTree(Container.java:1092)
at java.awt.Container.validateTree(Container.java:1099)
at java.awt.Container.validateTree(Container.java:1099)
at java.awt.Container.validateTree(Container.java:1099)
at java.awt.Container.validateTree(Container.java:1099)
at java.awt.Container.validateTree(Container.java:1099)
at java.awt.Container.validateTree(Container.java:1099)
at java.awt.Container.validateTree(Container.java:1099)
at java.awt.Container.validateTree(Container.java:1099)
at java.awt.Container.validate(Container.java:1067)
at java.awt.Window.dispatchEventImpl(Window.java:1604)
at java.awt.Component.dispatchEvent(Component.java:3477)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

Using Linux Fedora core 2.6.8-1.521



 Comments   
Comment by kbr [ 18/Feb/05 ]

Could you please attach a test case? I added you as an Observer of the jogl
project so you should be able to modify this bug now.

Comment by kbr [ 23/Feb/05 ]

Is this bug reproducible? If so, please attach a test case.

Comment by gusgus84 [ 23/Feb/05 ]

I won't have access to my Linux workstation for a few days to make a simplified
test case. But you can download the program I was testing with at
http://www.chem.byu.edu/Plone/people/rbshirts/research/Boltzmann3D.tar.gz
It's packaged with 1.1b07 because b09 isn't working, so just replace the libs
there with the new ones and it will throw that exception. I'll get you a
simplified test case by the end of the week when I can get to a linux
workstation

Comment by kbr [ 23/Feb/05 ]

Your Boltmann.jar works fine for me on my Red Hat AS 2.1 installation with an
NVidia GeForce FX 5800, NVidia's 66.29 drivers, and the current JOGL sources. My
ATI Linux box doesn't work any more due to bugs in their recent drivers, so I'm
afraid I can't help you if that's your configuration. Let me know if you can
boil down your program into a reproducible test case.

Comment by gusgus84 [ 08/Mar/05 ]

Still not fixed in b10. The RedHat Hardware browser says I have an Intel i740,
and I'm using the latest Mesa Drivers.

Comment by kbr [ 09/Apr/05 ]

Is this program still failing with JOGL 1.1 b10? If not I would like to close
this bug as "not reproducible".

Comment by kbr [ 11/Jan/06 ]

The JOGL implementation has been substantially rewritten in the development of
JSR-231 and is more correct in its synchronization of GLX commands than previous
implementations. Please try the latest nightly build if possible. Closing this
bug as not reproducible.





[JOGL-118] EXCEPTION_ACCESS_VIOLATION on show of 2nd canvas (ATI-specific) Created: 01/Nov/04  Updated: 30/Jan/05  Resolved: 30/Jan/05

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

Type: Bug Priority: Critical
Reporter: delwarl 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 2000
Platform: PC
URL: http://delsci.com/java/BuggyFrame.zip


Attachments: Zip Archive BuggyFrame.zip    
Issuezilla Id: 118

 Description   

Opening up a second JFrame & GLCanvas with a Menu action causes an
EXCEPTION_ACCESS_VIOLATION on Windows 2k with ATI hardware & drivers. The
problem does not occur with nVidia hardware under Windows or with ATI hardware
under Mac OS X. The latest beta (1.1b06) does not solve the problem.

A simple test app can be downloaded from the associated URL (BuggyFrame.zip).

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
PC=0x24F8A703
Function=DrvSetContext+0x11313
Library=E:\WINNT\system32\atioglxx.dll

at net.java.games.jogl.impl.windows.WGL.wglCreateContext(Native Method)
at net.java.games.jogl.impl.windows.WindowsGLContext.
choosePixelFormatAndCreateContext
(WindowsGLContext.java:495)

...



 Comments   
Comment by kbr [ 28/Jan/05 ]

Created an attachment (id=33)
Copy of submitter's test case

Comment by kbr [ 28/Jan/05 ]

This doesn't crash on my machine but the creation of the second GLCanvas does
fail with a GLException indicating that the pixel format of the second window
could not be set. This is almost certainly due to poor multithreading behavior
in ATI's drivers and interaction with the new dummyGL code; the question is
whether a good workaround can be found.

Comment by kbr [ 30/Jan/05 ]

The root cause of this bug was not the new DummyGL code, but severe bugs in
ATI's OpenGL drivers where it appears that if an OpenGL context is ever made
current on more than one thread during the lifetime of an application, problems
begin to occur such as the SetPixelFormat call failing on the just the next
newly-created HDC, or all subsequent SetPixelFormat calls failing on all
subsequently-created HDCs. This was occurring because the single-threaded ATI
workaround's automatic detection mechanism was not being enabled until the first
time a context was made current, but by then it was typically too late; the
context was made current on the end user's thread during e.g. Frame.show(), and
if it was ever made current on another thread (like the AWT event queue thread,
which is where all OpenGL operations are performed when the single-threaded
workaround is enabled) then the problems would begin.

The failure has only been seen on Windows so far; ATI's drivers on X11 seem to
be better behaved. The workaround is to check for the presence of ATI's drivers
very early during JOGL's initialization, by looking in the system directory for
atioglxx.dll, and enabling the single-threaded workaround if it was found. This
workaround causes the attached test case to work properly.

Comment by kbr [ 30/Jan/05 ]
      • Issue 130 has been marked as a duplicate of this issue. ***




[JOGL-111] GLCanvas and JTabbedPane incompatibility. Created: 05/Oct/04  Updated: 31/Jan/05  Resolved: 31/Jan/05

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

Type: Bug Priority: Critical
Reporter: nopalot 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


Attachments: Zip Archive GlCanvasTest.zip    
Issuezilla Id: 111

 Description   

Hello,
i tried to use a GLCanvas together with a JTabbedPane. Therefore i've inherited
a new class from JPanel which implements GLEventListener.
If i try to add one tab as a reaction of a user interaction (pushed button) the
program terminates with "Unable to set pixel format" GLException on windows or
with "Xlib: unexpected async reply (sequence 0x2d1)!" on linux.
However, if the tabs are added in the constructor of the class that creates the
JTabbedPane, everything works well.

Ive tried to fix the problem by creating just one GLCanvas which is used for
all tabs. (rather than creating a GLCanvas for each tab) But the same probem
appeared. This approach has also revealed that if one GLCanvas is added to
various tabs, only the last tab will display the GLCanvas. All previously
created tabs will 'lose' there GLCanvas object. (GLEventListener.display() is
no longer called automatically, calling GlCanvas.display() manualy doesnt
display anything....)

Please let me know if you need any further information.
Thanks in advance,
nop nop nop...



 Comments   
Comment by nopalot [ 05/Oct/04 ]

Created an attachment (id=17)
the prog displays a JTabbedPane using the same GLCanvas for each tab. adding a tab dynamically crashes the app.

Comment by kbr [ 31/Jan/05 ]

I no longer see crashes (on Windows) with the latest fixes to the
JOGL_SINGLE_THREADED_WORKAROUND for ATI cards, in particular recent
Windows-specific fixes. The changes are currently in the JOGL CVS repository and
will be present in JOGL 1.1 b08. Please retest once this version ships (or with
the current CVS sources) and reopen this bug if problems still occur. If they
do, please indicate whether specifying -DJOGL_SINGLE_THREADED_WORKAROUND=true on
the command line works around the issues.

Regarding adding heavyweights like GLCanvas to a JTabbedPane: the JTabbedPane is
a lightweight component and I would expect that adding a GLCanvas to it would
have all of the same problems (maybe more) as putting a GLCanvas into a
JInternalFrame. You will probably need to do some bookkeeping and manally add
and remove the GLCanvas depending on which tab is visible. We'll try to
accelerate the GLJPanel some more using pbuffers in an upcoming JOGL release for
better performance with full Swing compatibility.





[JOGL-78] Re-assigning rendering thread causes subsequent display() to fail Created: 26/Apr/04  Updated: 05/May/04  Resolved: 05/May/04

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

Type: Bug Priority: Critical
Reporter: yvg 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: 78

 Description   

Imagine I want to turn on FSAA on existing scene. I have GLCanvas created
(canvasA), set up and running, and its rendering thread set to rendering thread
of the app.

No the app wants to turn on FSAA. Inside the rendering thread, just after
canvasA.display() it calls canvasA.setRenderingThread(null), then creates new
canvasB with FSAA turned on, calls canvasB.setRenderingThread
(Thread.currentThread()), and then canvasB.display().

The code executing is similar to this:

GLCanvas canvasA = createCanvas(FSAA disabled);
canvasA.setRenderingThread(Thread.currentThread());
canvasA.display();
canvasA.setRenderingThread(null);
GLCanvas canvasB = createCanvas(FSAA enabled);
canvasB.setRenderingThread(Thread.currentThread());
canvasB.display();

In current implementation, canvasB.display() fails with "Surface already
unlocked" exception.

The reason of this problem is that in GLContext.invokeGL() during the handling
of canvasA.setRenderingThread(null) the second reference to canvasA's context
pushed, and before freeing only one of the references popped from the stack.
This causes that reference to context which is already freed left on the stack
and during the next call to canvasB.display() GLContext.invokeGL() tries to
free it again, which is invalid.

The simplest fix for this issue is to duplicate pop() operation for case when
freeing context after setRenderingThread(null), i.e. replace fragment

if (mustFreeBecauseOfNoRenderingThread) {
// Must match previous push()
ctxStack.pop();
}

with

if (mustFreeBecauseOfNoRenderingThread) {
// Must match previous push()
ctxStack.pop();
ctxStack.pop();
}

in GLContext.invokeGL().

I tried this fix and it solved the problem.

Yuri Vl. Gushchin
JProof



 Comments   
Comment by kbr [ 30/Apr/04 ]

The code in GLContext.invokeGL() which keeps track of which GLDrawables are in
the process of rendering on the current thread was buggy, largely because it was
too complicated. A restructuring and simplification has made it easier to
understand and has fixed Issue 80, which is probably identical to this one.

Please retest with the nightly build dated April 31 and update this bug
indicating whether this problem has been addressed. This fix will be present in
JOGL 1.1 beta 04.

Comment by kbr [ 05/May/04 ]

Submitter confirmed that new code fixes this issue.

Comment by kbr [ 05/May/04 ]
      • Issue 80 has been marked as a duplicate of this issue. ***




[JOGL-77] Creation of dummy GL context fails in some configurations Created: 26/Apr/04  Updated: 26/Apr/04  Resolved: 26/Apr/04

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

Type: Bug Priority: Critical
Reporter: yvg 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: 77

 Description   

In some configurations (esp. with ATI card, latest drivers, WinXP), creation of
dummy GL context fails when system tries to swap buffers on newly created dummy
context.

To fix this, I suggest to disable autoRedraws and automatic swapBuffers for
dummy context, because of it is not needed as far as dummy context is only used
to get extension strings and function pointers.

Proposed change is to add disabling code for these modes just after setting
zero size of GLCanvas in WindowsGLContextFactory.getDummyGLContext(...):

canvas.setSize(0, 0);
canvas.setNoAutoRedrawMode(true);
canvas.setAutoSwapBufferMode(false);

This change is proven to fix described wrong behavior and additionally provides
(really minor) improvement for app startup time (esp. if VSync is enabled).

Yuri Vl. Gushchin
JProof



 Comments   
Comment by kbr [ 26/Apr/04 ]

Thanks for the patch. It's been applied to the CVS repository.





[JOGL-76] Multisampling (FSAA) does not work on ATI Created: 24/Apr/04  Updated: 25/Apr/04  Resolved: 25/Apr/04

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

Type: Bug Priority: Critical
Reporter: yvg 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


Attachments: Text File ATImultisample.diff    
Issuezilla Id: 76

 Description   

Multisampling (FSAA) does not work on ATI cards.

For some reason ATI drivers return empty string for both
wglGetExtensionsStringEXT and wglGetExtensionsStringARB, so JOGL can not detect
presence of multisampling capabilities, and FSAA does not work. The same code
works fine on NVidia cards.

Other programs (Realtech VR OpenGL extension viewer and NeHe Lesson #46) show
that multisampling extensions are there and are able to use them.

After detalied investigation, I found that the problem caused by call to
wglGetExtensionsStringARB outside of GLEventListener methods. Moving request of
WGL extension string to init(...) method of GLEventListener associated with
dummyGL solves problem.

Suggested solution is: create additional map [device -> extensions string] in
WindowsGLContextFactory, fill it in init(...) method of GLEventListener
associated with dummyGL, and in
WindowsGLContext.choosePixelFormatAndCreateContext(...) use value from this map
instead of calling wglGetExtensionsStringARB directly.

See patch attached.

Yuri Vl. Gushchin
JProof



 Comments   
Comment by yvg [ 24/Apr/04 ]

Created an attachment (id=13)
Patch for fixing FSAA with ATI

Comment by kbr [ 25/Apr/04 ]

Thanks for the patch. It has been applied to the CVS repository and will show up
in the next nightly build as well as the next release build.





[JOGL-73] build.xml needs "-L/usr/X11R6/lib" for Linux. Created: 16/Apr/04  Updated: 19/Apr/04  Resolved: 19/Apr/04

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

Type: Bug Priority: Critical
Reporter: oic 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: 73

 Description   

Linux by default has the X11 library in /usr/X11R6/lib/libX11.so.
build.xml needs a "-L/usr/X11R6/lib" in the link options.

c.link.jogl:
[exec] /usr/bin/ld: cannot find -lX11
[exec] collect2: ld returned 1 exit status



 Comments   
Comment by kbr [ 19/Apr/04 ]

Apparently Red Hat 7.3 used to have a symlink for libX11.so in /usr/lib but
later versions do not. Fixed in the build.xml as suggested.





[JOGL-71] glMultiDrawElements() is missing Created: 09/Apr/04  Updated: 04/Oct/04  Resolved: 04/Oct/04

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

Type: Bug Priority: Critical
Reporter: mithrandir 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: 71

 Description   

glMultiDrawElements is defined as part of the core of OpenGL 1.4 and is not
provided in the given APIs. Strangely, glMultiDrawArrays() is included, which
was also introduced in OGL 1.4.



 Comments   
Comment by kbr [ 09/Apr/04 ]

GlueGen needs to be updated to handle the void ** argument that is a parameter
to this routine.

Comment by kbr [ 04/Oct/04 ]

Added support to GlueGen to handle pointer-to-pointer types for
primitive types, like void** and int**. These are exposed as arrays of
appropriately-typed direct java.nio Buffers for simplicity. Checks for
whether the buffers are direct are performed and null checks for the
individual Buffer objects are done as well. Fixed an existing bug in
the conversion of outgoing char** arguments in C to String[] in Java
where null checks were missing; this showed up as crashes in
glShaderSourceARB. Exposed glMultiDrawElements and several other
less-common entry points taking void** arguments.





[JOGL-63] NoAutoRedraw paint behavior Created: 06/Feb/04  Updated: 10/Jan/06  Resolved: 10/Jan/06

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

Type: Improvement Priority: Critical
Reporter: andyskinner 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: 63

 Description   

My issue #62 is the result of trying to get a complicated multi-threaded approach
to work with the assumption that the GLCanvas can only tell my app to do
something through the GLEventListener interface. I'd prefer a simpler approach
that skips those issues altogether.

I'd really like only only thread (my rendering thread) to deal with Jogl. However, I
do want to be able to render when the GLCanvas gets a paint event.

This is my suggestion, though I'd be open to other ways of achieving the same
thing:

In GLCanvas.paint(), add an else condition to the if that checks the autoredraw
mode. If autoredraws are turned off, call paint(g) on the GLCanvas's parent.

This allows me to set up GLCanvas, turn off autoredraw, and have my paint
method tell my rendering thread when it can go. Now I don't have to worry about
thread synchronization issues trying to share Jogl between AWT calling display()
and my rendering thread calling display(), and things are much cleaner.

I first thought of asking for another method on the GLEventListener interface, but I
don't want the call to go through invokeGL(), which is synchronized. Because I
want to be in control of Jogl, I just want GLCanvas to let me know when it would
have made a picture, so I could handle it in my own way (in addition to the way I
initiate making a picture on my own).

If there is a good way to handle this already, I'd be interested in hearing about it.
I'm trying to fit this into a large existing system, so I can't make too many
architectural changes to my own stuff.

thanks
andy



 Comments   
Comment by kbr [ 10/Jan/06 ]

The JSR-231 APIs have substantially revised the amount of control given to
applications as well as significantly changed how operations such as forcing all
GLAutoDrawable work on to a single thread are done. The NoAutoRedraw API has
been completely removed from the JSR-231 APIs as it is no longer necessary for
correctness. We believe the current JOGL implementation is significantly more
robust than earlier versions and request you try the current version if still
applicable.





[JOGL-64] Cannot compile the source static variable is missing in GLX.java Created: 16/Feb/04  Updated: 30/Apr/04  Resolved: 30/Apr/04

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

Type: Bug Priority: Critical
Reporter: bdr_act 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: 64

 Description   

...
GLX_DEPTH_SIZE
GLX_DOUBLEBUFFER

...

also

cannot find class:

XVisualInfo



 Comments   
Comment by kbr [ 16/Feb/04 ]

You need to use the build.xml in the make/ subdirectory and supply a concrete
target (i.e., "ant linux") so that the appropriate sources get generated. Please
indicate if you're already doing this.

Comment by kbr [ 17/Feb/04 ]
      • Issue 65 has been marked as a duplicate of this issue. ***
Comment by kbr [ 17/Feb/04 ]

Submitter indicated that Ant-based build process is being used. See issue 65.

The sources check out and build cleanly on my Red Hat 7.3 system with ANTLR
2.7.2, Ant 1.5.3, and the Sun Java 2 SDK 1.4.2_xx. I suspect there may be
problems with later versions of Ant (i.e., the 1.6 tree) but have not yet tested
with it. Please make sure the Ant, ANTLR, and J2SDK versions match and indicate
whether that fixes the problem.

Comment by kbr [ 30/Apr/04 ]

Current build.xml has been fixed to work with all versions of Ant.





[JOGL-57] JOGL build fails on Mac OS X. Created: 13/Jan/04  Updated: 30/Apr/04  Resolved: 30/Apr/04

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

Type: Bug Priority: Critical
Reporter: oic Assignee: jogl-issues
Resolution: Fixed 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: 57

 Description   

JOGL build fails on Mac OS X with the following error:

/Users/gamesbld/games/build/0230011304/jogl/make/build-gluegen.xml:122: ANTLR si
gnaled an error: ANTLR Parser Generator Version 2.7.2 1989-2003 jGuru.com
error: cannot find/copy importVocab file /Users/gamesbld/games/build/0230011304/
jogl/src/net/java/games/gluegen/cgram/STDCTokenTypes.txt

Full build log is available upon request.



 Comments   
Comment by kbr [ 30/Apr/04 ]

Fixed in current build.





[JOGL-56] Requesting a framebuffer with an alpha component fails. Created: 30/Nov/03  Updated: 30/Apr/04  Resolved: 30/Apr/04

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

Type: Bug Priority: Critical
Reporter: orangytang 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: 56

 Description   

If a framebuffer with an alpha component is requested via a GLCapabilities object
then an exception will always be thrown when trying to display the newly created
canavs: net.java.games.jogl.GLException: Error making context current

Has occured on two separate linux systems now, both of which will run Jogl demos
without an alpha framebuffer without complaint, and which will sucessfully create
an alpha framebuffer using LWJGL.



 Comments   
Comment by kbr [ 30/Apr/04 ]

The X11 visual selection code has been rewritten as of JOGL 1.1 beta 01. This
issue should now be fixed. Please reopen this issue or file a new one if not.





[JOGL-52] Current GLU semantics need to be properly encapsulated Created: 21/Nov/03  Updated: 30/Jan/05  Resolved: 30/Jan/05

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

Type: Improvement Priority: Critical
Reporter: gregorypierce 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: 52

 Description   

Currently the GLU engine requires that you use certain functions such as
GLU.newQuadric() in order to get a new GLUQuadric. However, the constructure for
GLUQuadric is public such that new users do what they expect would work in OO and
perform the operation:

new GLUQuadric()

This will work at the API level and will not fail until you try to actually render the Quadric.
Since the desired behavior is to use the GLU factory functions, the constructors for these
classes absolutely needs to become package private so that users to not get themselves
into awkward situations with respect to the Quadrics.



 Comments   
Comment by kbr [ 30/Jan/05 ]

This has been fixed with the recent incorporation of the LWJGL team's port of
the GLU quadric code to pure Java.





[JOGL-42] Problems invoking GLU functions Created: 14/Sep/03  Updated: 23/Feb/05  Resolved: 23/Feb/05

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

Type: Bug Priority: Critical
Reporter: yvg 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: 42

 Description   

When trying to call GLU functions under Linux, JVM crashed in native code.
The example is taken from the forum at javagaming.org, topic "Picking". The code
works fine when code for glu functions replaced with equivalent code in Java. I
can send the test code if needed.

System information:

Linux RedHat 9
VIA CLE266
JDK 1.4.2

The crash info:

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0xEF1
Function=[Unknown.]
Library=(N/A)

NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.

Current Java thread:
at net.java.games.jogl.impl.GLUImpl.dispatch_gluPerspective(Native
Method)
at net.java.games.jogl.impl.GLUImpl.gluPerspective(GLUImpl.java:935)
at com.jproof.xith3d.test.PickTest1.reshape(PickTest1.java:393)
at net.java.games.jogl.impl.GLDrawableHelper.reshape
(GLDrawableHelper.java:81)
at net.java.games.jogl.GLCanvas$1.run(GLCanvas.java:108)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:189)

  • locked <0x44c1cef8> (a
    net.java.games.jogl.impl.x11.X11OnscreenGLContext)
    at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:182)
    at net.java.games.jogl.GLCanvas.display(GLCanvas.java:82)
    at net.java.games.jogl.Animator$1.run(Animator.java:104)
    at java.lang.Thread.run(Thread.java:534)

Dynamic libraries:
08048000-0804e000 r-xp 00000000 03:03
622584 /usr/java/j2sdk1.4.2/jre/bin/java
0804e000-0804f000 rw-p 00005000 03:03
622584 /usr/java/j2sdk1.4.2/jre/bin/java
40000000-40015000 r-xp 00000000 03:03 621437 /lib/ld-2.3.2.so
40015000-40016000 rw-p 00014000 03:03 621437 /lib/ld-2.3.2.so
40017000-4001f000 r-xp 00000000 03:03
655913 /usr/java/j2sdk1.4.2/jre/lib/i386/native_threads/libhpi.so
4001f000-40020000 rw-p 00007000 03:03
655913 /usr/java/j2sdk1.4.2/jre/lib/i386/native_threads/libhpi.so
40020000-40024000 rw-s 00000000 03:03 754653 /tmp/hsperfdata_root/6774
40025000-4002f000 r-xp 00000000 03:03 556062 /lib/tls/libpthread-0.29.so
4002f000-40030000 rw-p 0000a000 03:03 556062 /lib/tls/libpthread-0.29.so
40032000-40034000 r-xp 00000000 03:03 621448 /lib/libdl-2.3.2.so
40034000-40035000 rw-p 00002000 03:03 621448 /lib/libdl-2.3.2.so
40036000-4042d000 r-xp 00000000 03:03
230982 /usr/java/j2sdk1.4.2/jre/lib/i386/client/libjvm.so
4042d000-40448000 rw-p 003f6000 03:03
230982 /usr/java/j2sdk1.4.2/jre/lib/i386/client/libjvm.so
4045b000-4046d000 r-xp 00000000 03:03 621452 /lib/libnsl-2.3.2.so
4046d000-4046e000 rw-p 00011000 03:03 621452 /lib/libnsl-2.3.2.so
40470000-40491000 r-xp 00000000 03:03 556060 /lib/tls/libm-2.3.2.so
40491000-40492000 rw-p 00020000 03:03 556060 /lib/tls/libm-2.3.2.so
40492000-40495000 r--s 00000000 03:03
558044 /usr/java/j2sdk1.4.2/jre/lib/ext/dnsns.jar
40495000-4049c000 r-xp 00000000 03:03 294798 /usr/X11R6/lib/libXp.so.6.2
4049c000-4049d000 rw-p 00006000 03:03 294798 /usr/X11R6/lib/libXp.so.6.2
4049d000-4049e000 r-xp 00000000 03:03
460190 /usr/java/j2sdk1.4.2/jre/lib/i386/libjawt.so
4049e000-4049f000 rw-p 00000000 03:03
460190 /usr/java/j2sdk1.4.2/jre/lib/i386/libjawt.so
404a0000-404ab000 r-xp 00000000 03:03 621458 /lib/libnss_files-2.3.2.so
404ab000-404ac000 rw-p 0000a000 03:03 621458 /lib/libnss_files-2.3.2.so
404ac000-404bc000 r-xp 00000000 03:03
460202 /usr/java/j2sdk1.4.2/jre/lib/i386/libverify.so
404bc000-404be000 rw-p 0000f000 03:03
460202 /usr/java/j2sdk1.4.2/jre/lib/i386/libverify.so
404be000-404de000 r-xp 00000000 03:03
460188 /usr/java/j2sdk1.4.2/jre/lib/i386/libjava.so
404de000-404e0000 rw-p 0001f000 03:03
460188 /usr/java/j2sdk1.4.2/jre/lib/i386/libjava.so
404e0000-404f4000 r-xp 00000000 03:03
460203 /usr/java/j2sdk1.4.2/jre/lib/i386/libzip.so
404f4000-404f7000 rw-p 00013000 03:03
460203 /usr/java/j2sdk1.4.2/jre/lib/i386/libzip.so
404f7000-41e82000 r--s 00000000 03:03
525095 /usr/java/j2sdk1.4.2/jre/lib/rt.jar
41ecc000-41ee2000 r--s 00000000 03:03
525094 /usr/java/j2sdk1.4.2/jre/lib/sunrsasign.jar
41ee2000-41fbd000 r--s 00000000 03:03
525093 /usr/java/j2sdk1.4.2/jre/lib/jsse.jar
41fbd000-41fce000 r--s 00000000 03:03
525085 /usr/java/j2sdk1.4.2/jre/lib/jce.jar
41ff6000-41ffa000 r-xp 00000000 03:03 294808 /usr/X11R6/lib/libXtst.so.6.1
41ffa000-41ffb000 rw-p 00004000 03:03 294808 /usr/X11R6/lib/libXtst.so.6.1
41ffb000-41ffc000 r-xp 00000000 03:03
491001 /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2
41ffc000-41ffd000 rw-p 00000000 03:03
491001 /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2
41ffd000-41fff000 rw-s cc951000 03:03 114720 /dev/dri/card0
42000000-4212e000 r-xp 00000000 03:03 556058 /lib/tls/libc-2.3.2.so
4212e000-42131000 rw-p 0012e000 03:03 556058 /lib/tls/libc-2.3.2.so
42133000-4268c000 r--s 00000000 03:03
525086 /usr/java/j2sdk1.4.2/jre/lib/charsets.jar
4c910000-4cb10000 r--p 00000000 03:03 474322 /usr/lib/locale/locale-archive
4cd10000-4cd1d000 r--s 00000000 03:03
558045 /usr/java/j2sdk1.4.2/jre/lib/ext/ldapsec.jar
4cd1d000-4cdd9000 r--s 00000000 03:03
558327 /usr/java/j2sdk1.4.2/jre/lib/ext/localedata.jar
4cdd9000-4cdf5000 r--s 00000000 03:03
558047 /usr/java/j2sdk1.4.2/jre/lib/ext/sunjce_provider.jar
4cdf5000-4ce4c000 r--s 00000000 03:03 753912 /yvg2/test/log4j-1.2.8.jar
4ce4c000-4ce6b000 r--s 00000000 03:03 753918 /yvg2/test/xith_utilities.jar
4ce6b000-4ceb2000 r--s 00000000 03:03 753916 /yvg2/test/vecmath.jar
4ceb2000-4cf15000 r--s 00000000 03:03 753917 /yvg2/test/xith3d.jar
4cf15000-4cf9d000 r--s 00000000 03:03 753910 /yvg2/test/jogl.jar
4cf9d000-4d268000 r-xp 00000000 03:03
460180 /usr/java/j2sdk1.4.2/jre/lib/i386/libawt.so
4d268000-4d27d000 rw-p 002ca000 03:03
460180 /usr/java/j2sdk1.4.2/jre/lib/i386/libawt.so
4d2a3000-4d2f6000 r-xp 00000000 03:03
460197 /usr/java/j2sdk1.4.2/jre/lib/i386/libmlib_image.so
4d2f6000-4d2f7000 rw-p 00052000 03:03
460197 /usr/java/j2sdk1.4.2/jre/lib/i386/libmlib_image.so
4d2f7000-4d2fd000 r-s 00000000 03:03 392710 /usr/lib/gconv/gconv
modules.cache
4d2fd000-4d304000 r-xp 00000000 03:03
294804 /usr/X11R6/lib/libXrender.so.1.2
4d304000-4d305000 rw-p 00006000 03:03
294804 /usr/X11R6/lib/libXrender.so.1.2
4d305000-4d353000 r-xp 00000000 03:03 294806 /usr/X11R6/lib/libXt.so.6.0
4d353000-4d357000 rw-p 0004d000 03:03 294806 /usr/X11R6/lib/libXt.so.6.0
4d357000-4d364000 r-xp 00000000 03:03 294784 /usr/X11R6/lib/libXext.so.6.4
4d364000-4d365000 rw-p 0000c000 03:03 294784 /usr/X11R6/lib/libXext.so.6.4
4d365000-4d441000 r-xp 00000000 03:03 294774 /usr/X11R6/lib/libX11.so.6.2
4d441000-4d444000 rw-p 000db000 03:03 294774 /usr/X11R6/lib/libX11.so.6.2
4d444000-4d44c000 r-xp 00000000 03:03 294772 /usr/X11R6/lib/libSM.so.6.0
4d44c000-4d44d000 rw-p 00007000 03:03 294772 /usr/X11R6/lib/libSM.so.6.0
4d44d000-4d461000 r-xp 00000000 03:03 294768 /usr/X11R6/lib/libICE.so.6.3
4d461000-4d462000 rw-p 00013000 03:03 294768 /usr/X11R6/lib/libICE.so.6.3
4d464000-4d47e000 r--s 00000000 03:03 753909 /yvg2/test/jogl-demos.jar
4d47e000-4d875000 r-s 00000000 03:03 753907 /yvg2/test/jogl-demos
data.jar
4d875000-4d896000 r--s 00000000 03:03 753908 /yvg2/test/jogl-demos-util.jar
4d896000-4d94e000 r-xp 00000000 03:03 753911 /yvg2/test/libjogl.so
4d94e000-4d94f000 rw-p 000b7000 03:03 753911 /yvg2/test/libjogl.so
4d94f000-4d9cb000 r-xp 00000000 03:03 640678 /dri-
cvs/build/xc/lib/GL/GL/libGL.so.1.2
4d9cb000-4d9d0000 rw-p 0007c000 03:03 640678 /dri-
cvs/build/xc/lib/GL/GL/libGL.so.1.2
4d9d1000-4da4c000 r-xp 00000000 03:03 296856 /usr/X11R6/lib/libGLU.so.1.3
4da4c000-4da4e000 rw-p 0007a000 03:03 296856 /usr/X11R6/lib/libGLU.so.1.3
4da4e000-4daf7000 r-xp 00000000 03:03 359971 /usr/lib/libstdc++.so.5.0.3
4daf7000-4dafc000 rw-p 000a9000 03:03 359971 /usr/lib/libstdc++.so.5.0.3
4db01000-4db08000 r-xp 00000000 03:03 621507 /lib/libgcc_s-3.2.2-
20030225.so.1
4db08000-4db09000 rw-p 00007000 03:03 621507 /lib/libgcc_s-3.2.2-
20030225.so.1
4db09000-4dbc3000 r-xp 00000000 03:03
460184 /usr/java/j2sdk1.4.2/jre/lib/i386/libfontmanager.so
4dbc3000-4dbdd000 rw-p 000b9000 03:03
460184 /usr/java/j2sdk1.4.2/jre/lib/i386/libfontmanager.so
4dbde000-4dbe7000 rw-s dc000000 03:03 114720 /dev/dri/card0
4dbec000-4dbf4000 r-xp 00000000 03:03
294782 /usr/X11R6/lib/libXcursor.so.1.0
4dbf4000-4dbf5000 rw-p 00007000 03:03
294782 /usr/X11R6/lib/libXcursor.so.1.0
4dbf5000-4dc11000 r-xp 00000000 03:03
490999 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
4dc11000-4dc13000 rw-p 0001c000 03:03
490999 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
4de93000-4e085000 r-xp 00000000 03:03 101055 /dri-
cvs/build/xc/lib/GL/mesa/src/drv/via/via_dri.so
4e085000-4e089000 rw-p 001f2000 03:03 101055 /dri-
cvs/build/xc/lib/GL/mesa/src/drv/via/via_dri.so
4e094000-52094000 rw-s d8000000 03:03 114720 /dev/dri/card0
52094000-54094000 rw-s d0000000 03:03 114720 /dev/dri/card0

Heap at VM Abort:
Heap
def new generation total 576K, used 292K [0x44710000, 0x447b0000,
0x44bf0000)
eden space 512K, 44% used [0x44710000, 0x447490e0, 0x44790000)
from space 64K, 100% used [0x44790000, 0x447a0000, 0x447a0000)
to space 64K, 0% used [0x447a0000, 0x447a0000, 0x447b0000)
tenured generation total 1408K, used 352K [0x44bf0000, 0x44d50000,
0x48710000)
the space 1408K, 25% used [0x44bf0000, 0x44c48040, 0x44c48200,
0x44d50000)
compacting perm gen total 4352K, used 4345K [0x48710000, 0x48b50000,
0x4c710000)
the space 4352K, 99% used [0x48710000, 0x48b4e670, 0x48b4e800,
0x48b50000)

Local Time = Sun Sep 14 18:45:53 2003
Elapsed Time = 3
#

  1. The exception above was detected in native code outside the VM
    #
  2. Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode)
    #

Yuri



 Comments   
Comment by kbr [ 09/Sep/04 ]

Several users have reported crashes while invoking GLU routines on Linux. As
recommended by the LWJGL group, the best solution is probably to just port the
GLU routines to pure Java and stop using the underlying GLU library.

Comment by kbr [ 18/Nov/04 ]

Incorporated the LWJGL team's port of the GLU quadric and projection routines to
be able to eliminate calls to the native GLU library for these cases, which was
problematic on certain Linux distributions. Still need to port at least some of
the mipmap routines and the NURBS tesselator.

Comment by kbr [ 23/Feb/05 ]

User GKW on java.net and the javagaming.org forums has ported the GLU mipmap
library to pure Java. After a few bug fixes to this port it appears to be
working very solidly. It addresses these strange crashes on various Linux
distributions so this bug is being closed as fixed (even though we don't
currently have a port of the GLU NURBS library).





[JOGL-39] Window creation in JOGL is dependent on visual order Created: 10/Sep/03  Updated: 30/Apr/04  Resolved: 30/Apr/04

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

Type: Bug Priority: Critical
Reporter: deronj 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: Sun


Issuezilla Id: 39

 Description   

JOGL programs flash on my FFB3 device (latest patch) because the window is
getting created with a single buffered visual.

Here is a discussion with Ken Russel which has the details.

Ken writes:

> What
>happens if the OpenGL context's selected visual and the widget's underlying
>visual (if there is one – I'm not clear on how this works) don't match? Is
>this what's happening, so that the OpenGL context is being constrained to the
>limitations of the widget's visual when it's made current?

I believe this is precisely what is happening. After talking to the
FFB3 DDX engineer I now understand why I am seeing the flashing when no
one else is. The reason is because, on most devices, the double buffered
24-bit gamma corrected visual (the one JOGL prefers) comes first on the
X visual list. When AWT (or 2D or whatever) creates the 24-bit window
(I'm still not sure how it knows the window is 24-bits) it uses the
first visual encountered. For most devices this works. But it turns
out that the ZFB family of devices (FFB3, Zulu, and DhakaZulu) are different.
Recently, the DDX engineer for these products was asked to reorder the visual
list to put the single buffered visuals first (to address some other problem).
So on my FFB3 device, the window is created in a single buffer visual.

What this suggests to me is that the current method that JOGL programs use
to create the window and the context has a dependency on the order of the
visuals in the visual list. I don't think we want the current scheme to
persist because we have no control over the visual orders of the various
platforms JOGL supports. And visual orders may change over time.

I think we need to modify the way that JOGL programs create their window and
context in order to eliminate this visual order dependency. The method that
Java3D uses could serve as a possible guide. Here is what Java3D does:

1. The J3D program calls J3D to get the "preferred" GraphicsConfiguration
(J3D also provides mechanisms for users to select a GraphicsConfiguration
with desired capabilities).

2. The program creates a Canvas3D using the Graphics Configuration. (I'm
guessing that this creates both a window and a context--Dan Petersen
can probably confirm this).

The GraphicsConfiguration class acts as an abstraction for a visual.
If the JOGL user were to choose the GraphicsConfiguration first and then
use this to create both the window and context (via a JOGL API call) then
the visual order dependency problem would go away.



 Comments   
Comment by kbr [ 30/Apr/04 ]

The X11 visual selection code has been rewritten as of JOGL 1.1 beta 01. This
issue should now be fixed. Please reopen this issue or file a new one if not.





[JOGL-35] VM crashes with "EXCEPTION_STACK_OVERFLOW" when binding a CG fragment program Created: 01/Sep/03  Updated: 31/Jan/05  Resolved: 31/Jan/05

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

Type: Bug Priority: Critical
Reporter: sbonneau 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 2000
Platform: PC


Attachments: Zip Archive repro.zip    
Issuezilla Id: 35

 Description   

Any time I try to bind a fragment program with CgGL.cgGLBindProgram(), the VM
crashes with EXCEPTION_STACK_OVERFLOW. I've looked into the JNI glue code
that's generated for this function, and nothing looks out of the ordinary. I even
went so far as to write a C-based version of my test program to make sure that it
wasn't something screwy with the CG configuration on my box.

Here's an excerpt from the error log that the VM generates:

--------------
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_STACK_OVERFLOW (0xc00000fd) occurred at
PC=0x2A8E8BB7
Function=[Unknown.]
Library=C:\Program Files\NVIDIA Corporation\Cg\bin\cgGL.dll

NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.

Current Java thread:
at net.java.games.cg.CgGL.cgGLBindProgram0(Native Method)
at net.java.games.cg.CgGL.cgGLBindProgram(CgGL.java:894)
at Main$Renderer.display(Main.java:54)
at net.java.games.jogl.impl.GLDrawableHelper.display
(GLDrawableHelper.java:74)
at net.java.games.jogl.GLCanvas$DisplayAction.run(GLCanvas.java:208)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:192)

  • locked <0x100a02f8> (a
    net.java.games.jogl.impl.windows.WindowsOnscreenGLContext)
    at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:196)
    at net.java.games.jogl.GLCanvas.display(GLCanvas.java:91)
    at net.java.games.jogl.Animator$1.run(Animator.java:104)
    at java.lang.Thread.run(Thread.java:534)
    -----------

The specs that I'm running with are the following:

Windows 2000
GeForce4 Ti 4200 (driver v6.14.10.4403)
CG Toolkit v1.1.307.700
JDK 1.4.2

My JoGL binaries were built locally from freshly updated sources using VC6. I can't
think of anything else off the top of my head that might be relevant.

I'll attach a zip file containing the source for a boiled-down test that reliably
reproeduces the crash for me, the corresponding pre-compiled binaries, and hte
hs_err_pid<ID> log file that the VM generated.



 Comments   
Comment by sbonneau [ 01/Sep/03 ]

Created an attachment (id=9)
Contains the VM error log, as well as the source and binaries for my repro test case.

Comment by kbr [ 31/Jan/05 ]

Sorry for not commenting on this earlier. I am pretty sure this is a bug in the
submitter's test case. I haven't found any examples of Cg programs on the net
that bind a fragment program exclusively, in particular one which doesn't take
any input parameters. I'm going to mark this as invalid, as the Cg demos which
are in the jogl-demos project work fine. If you can come up with a boiled-down
test case that works in the C programming language but not in Java with JOGL's
Cg bindings then please reopen this bug or file a new one and attach both
languages' test cases.





[JOGL-16] Accessibility breaks jogl Created: 23/Jun/03  Updated: 14/Jul/03  Resolved: 14/Jul/03

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

Type: Bug Priority: Critical
Reporter: rmm20 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 2000
Platform: All


Issuezilla Id: 16

 Description   

If Java accessibility.properties is set to:
assistive_technologies=com.sun.java.accessibility.AccessBridge

the jawt.dll is loaded twice, with bad results:
This fails on both demos:

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\>cd jogl\jogl\demos

CC:\jogl\jogl\demos\vertexArrayRange>java VertexArrayRange
Exception in thread "main" java.lang.UnsatisfiedLinkError: Native Library D:\Pro
gram Files\Java\j2re1.4.1_02\bin\jawt.dll already loaded in another classloader
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1437)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1389)
at java.lang.Runtime.loadLibrary0(Runtime.java:788)
at java.lang.System.loadLibrary(System.java:832)
at com.sun.java.accessibility.AccessBridge$2.run(AccessBridge.java:736)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.java.accessibility.AccessBridge.<init>(AccessBridge.java:733)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct
orAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC
onstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:306)
at java.lang.Class.newInstance(Class.java:259)
at java.awt.Toolkit.loadAssistiveTechnologies(Toolkit.java:652)
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:738)
at java.awt.Window.getToolkit(Window.java:675)
at java.awt.Window.init(Window.java:239)
at java.awt.Window.<init>(Window.java:268)
at java.awt.Frame.<init>(Frame.java:398)
at VertexArrayRange.run(VertexArrayRange.java:192)
at VertexArrayRange.main(VertexArrayRange.java:160)

Removing accessibility.properties from java jre\lib eliminates this error.
It also eliminates accessibility.

Robert Mitchell



 Comments   
Comment by kbr [ 30/Jun/03 ]

Probably fixable by catching UnsatisfiedLinkError in NativeLibLoader and looking
for the string "already loaded" in the detail message. Gross, but will work
without having to add native code to load jawt.dll / libjawt.so.

Comment by kbr [ 14/Jul/03 ]

I wasn't able to reproduce the UnsatisfiedLinkError below after installing the
AccessBridge, but have still put in a clause looking for a detail message
containing "already loaded" and skipping the exception in this case.





[JOGL-14] Incorrect rendering when calling glOrtho() outside of GLDrawable.reshape() Created: 22/Jun/03  Updated: 22/Jun/03  Resolved: 22/Jun/03

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

Type: Bug Priority: Critical
Reporter: ckline Assignee: kbr
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 2000
Platform: PC
URL: http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1056274375


Issuezilla Id: 14

 Description   

Please see the attached reproduction case. When this program is compiled with
setCameraInRepaint=true, the app renders correctly (diagonal and vertical lines,
plus a small box at bottom left corner). When setCameraInRepaint is false, nothing
renders.

I am unsure as to why the app does not render correctly in the second case,
since glOrtho() is being called in display() and hence should be called after the call
to glViewport() is made in GLCanvas.reshape().

I suspect some strange behavior with respect to the AWT integration and
threading – perhaps because GLCanvas.reshape() is called in a different thread
from that used to call GLDrawable.reshape()?

--------

import java.awt.Frame;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;

import net.java.games.jogl.*;

/**

  • Vectrix
  • @author John
  • @author Ckline modified to demostrate bug
    */
    public class Vectrix implements GLEventListener
    {
    // BUG REPRO: app does not render correctly when setCameraInReshape is false
    private boolean setCameraInReshape = true;

public static Vectrix app = new Vectrix();

private Frame frame;

// private MouseHandler mouseHandler;
private Animator animator;

private GLCanvas canvas;

/**

  • */
    private Vectrix()
    {
    System.out.println("Vectrix instance created");

// Canvas setup
GLCapabilities caps = new GLCapabilities();
caps.setDoubleBuffered(true);
caps.setAlphaBits(8);
caps.setStencilBits(8);
canvas = GLDrawableFactory.getFactory().createGLCanvas(caps);

//canvas = GLDrawableFactory.getFactory().createGLCanvas(new GLCapabilities
());
canvas.addGLEventListener(this);
canvas.setGL(new DebugGL(canvas.getGL()));
// Frame setup
frame = new Frame("Vectrix");
frame.add(canvas);
frame.setSize(800, 600);

frame.addWindowListener(
new WindowAdapter()
{
public void windowClosing(WindowEvent e)

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

}
);

// Event handlers
animator = new Animator(canvas);
}

public void initialiseDisplay()

{ frame.show(); }

public void run()

{ animator.start(); }

public static void main(String[] args)

{ System.out.println("Vectrix starting..."); app = new Vectrix(); app.initialiseDisplay(); // Other loading/initialisation // .. // Start main game loop app.run(); }

// GL Event Listener methods

// Called when GL has been initialised for the first time.
public void init(GLDrawable canvas)

{ System.out.println("Vectrix.init(): GL init event"); GL gl = canvas.getGL(); gl.glMatrixMode(GL.GL_PROJECTION); gl.glLoadIdentity(); gl.glMatrixMode(GL.GL_TEXTURE); gl.glLoadIdentity(); gl.glMatrixMode(GL.GL_MODELVIEW); gl.glLoadIdentity(); }

public void display(GLDrawable canvas)
{
//System.err.println("DISPLAY THREAD: " + Thread.currentThread());
GL gl = canvas.getGL();
GLU glu = canvas.getGLU();

gl.glClearColor(0.2f, 0.2f, 0.2f, 0.0f);
gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT |
GL.GL_STENCIL_BUFFER_BIT);

if (!setCameraInReshape)

{ // l/r b/t near/far gl.glMatrixMode(GL.GL_PROJECTION); gl.glOrtho(0, 4, 0, 3, -8, 8); gl.glMatrixMode(GL.GL_MODELVIEW); }

gl.glPushMatrix();
{
// draw a polygon
gl.glBegin(GL.GL_POLYGON);
gl.glColor3f(1f, 0f, 0f);
gl.glVertex3f(.25f, .25f, 0f);
gl.glVertex3f(.75f, .25f, 0f);
gl.glVertex3f(.75f, .75f, 0f);
gl.glVertex3f(.25f, .75f, 0f);
gl.glEnd();

// draw some lines
gl.glBegin(GL.GL_LINES);
{
int xMin = 0;
int xMax = 10;
gl.glColor3f(1f, 0f, 0f);

for (int x=xMin; x<=xMax; x++)

{ gl.glVertex3f(x, -1, 0f); gl.glVertex3f(x, +1, 0f); }

gl.glVertex3f(0f, 0f, 0f);
gl.glVertex3f(4f, 4f, 4f);

}
gl.glEnd();

}
gl.glPopMatrix();

}

public void reshape(GLDrawable arg0, int arg1, int arg2, int arg3, int arg4)
{
//System.err.println("RESHAPE THREAD: " + Thread.currentThread());
GL gl = arg0.getGL();

System.out.println("Vectrix.init(): GL reshape event " + arg1 + " " + arg2
+ " " + arg3 + " " + arg4);

if (setCameraInReshape)

{ // l/r b/t near/far gl.glMatrixMode(GL.GL_PROJECTION); gl.glOrtho(0, 4, 0, 3, -8, 8); }

}

public void displayChanged(GLDrawable arg0, boolean arg1, boolean arg2)
{

}
}



 Comments   
Comment by ckline [ 22/Jun/03 ]

This bug was initiated from the discussion at

http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?
board=jogl;action=display;num=1056274375

Comment by ckline [ 22/Jun/03 ]

After some experimentation, I now believe this is not a bug. If you change all the
calls around glOrtho() to look like this:

gl.glMatrixMode(gl.GL_PROJECTION)
gl.glLoadIdentity()
gl.glOrtho(...)
gl.glMatrixMode(gl.GL_MODELVIEW)

the app works correctly regardless of the value of setCameraInReshape. Unless
further issues crop up, I would like to declare this not-a-bug.





[JOGL-5] Multi head support broken Created: 13/Jun/03  Updated: 30/Apr/04  Resolved: 30/Apr/04

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

Type: Bug Priority: Critical
Reporter: paulby 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


Issuezilla Id: 5

 Description   

Running the gear demo on a multi (2) head workstation the JFrame appears on
screen 1 but the opengl native window appears on screen 0.

System is Solaris 9, JDK 1.4.2 beta (b19), dual IFB, no xinerama.



 Comments   
Comment by kbr [ 30/Jun/03 ]

Probably problem in hardwiring of Display or RootWindow routines. Was unclear at
the time how to do this properly. Will need to find machine to test on or get
assistance from user in testing any fix.

Comment by kbr [ 30/Apr/04 ]

The X11 visual selection code has been rewritten as of JOGL 1.1 beta 01. It
should fix this issue. Please reopen this issue or file a new one if not.





[JOGL-289] GLJPanel show after hide causes GLException Created: 17/Mar/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: Critical
Reporter: chrisnf Assignee: jogl-issues
Resolution: Duplicate 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: 289

 Description   

This bug was already reported as 274 but I'm not sure how to add a comment. I
could just vote, but I want to mention new info. It also happens with me when I
put a GLJPanel on a JTabbedPane. When the tab is shown, it's ok. When it is
hidden then shown again, I get the exception:

exception in QueueFlusher:
javax.media.opengl.GLException: Unable to create OpenGL context for device
context 0x74012321
...

As advised in 274, with -Dsun.opengl.fbobject=false it seems not to happen.

However, I'm using an ATI Radeon X550 with the latest JOGL and ATI drivers, not
NVIDIA. It seems this fbobject problem is common to both.

Chris



 Comments   
Comment by kbr [ 21/Mar/07 ]

If you're registered as an Observer of the JOGL project you can comment on bugs.
I've copied your comment into Issue 274.

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




[JOGL-272] Move setColor method from TextRenderer up to TextureRenderer Created: 18/Feb/07  Updated: 19/Feb/07  Resolved: 19/Feb/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: All


Issuezilla Id: 272

 Description   

The thread http://www.javagaming.org/forums/index.php?topic=15914.0 indicates
that the setColor method on TextRenderer should also be available on the
TextureRenderer.



 Comments   
Comment by kbr [ 19/Feb/07 ]

Moved setColor() implementation from TextRenderer to TextureRenderer and
reimplemented TextRenderer's methods in terms of it.





[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 [ 27/Feb/07 ]

Downgrading to normal priority.

Comment by kbr [ 21/Mar/07 ]

Copying in comments from user chrisnf from Issue 289, which is a duplicate of
this one:

This bug was already reported as 274 but I'm not sure how to add a comment. I
could just vote, but I want to mention new info. It also happens with me when I
put a GLJPanel on a JTabbedPane. When the tab is shown, it's ok. When it is
hidden then shown again, I get the exception:

exception in QueueFlusher:
javax.media.opengl.GLException: Unable to create OpenGL context for device
context 0x74012321
...

As advised in 274, with -Dsun.opengl.fbobject=false it seems not to happen.

However, I'm using an ATI Radeon X550 with the latest JOGL and ATI drivers, not
NVIDIA. It seems this fbobject problem is common to both.

Chris

Comment by kbr [ 21/Mar/07 ]
      • Issue 289 has been marked as a duplicate of this issue. ***
Comment by kbr [ 21/Mar/07 ]

Added chrisnf to CC: list

Comment by kbr [ 21/Mar/07 ]

Investigation revealed that the symptom was similar to what happens
when one tries to create a new OpenGL context against an invalid HDC
on Windows. Discussion with Chris Campbell from the Java 2D team
indicated that in situations where the Java 2D OpenGL pipeline is
using Frame Buffer Objects for its rendering, it is possible that its
internal OpenGL context can be left current to the on-screen drawable,
and it only has a valid device context for the brief period of time
when its OpenGL context was being made current. This means that by the
time JOGL's code got a chance to run, it did not have a valid HDC and
therefore could not create its OpenGL context against it. The
workaround, suggested by Chris, is to forcibly make the Java 2D
context current against its internal "scratch" pbuffer, which can be
done with the internal invokeWithOGLSharedContextCurrent method. Added
this workaround and verified it fixes the problem with the user's test
case. This issue will be fixed in a forthcoming Java SE 6 update
release, hopefully 6u2.

The fix for this bug will be present in nightly builds dated 3/22 and later.





[JOGL-273] class DDSImage don't support cubemap textures Created: 20/Feb/07  Updated: 20/Feb/07  Resolved: 20/Feb/07

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

Type: Improvement Priority: Major
Reporter: bandures 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 Source File DDSImage.java    
Issuezilla Id: 273

 Description   

DDSImage can't load cubemap DDS files. I attached new version with cubemap support.



 Comments   
Comment by bandures [ 20/Feb/07 ]

Created an attachment (id=90)
DDSImage class with cubemap support

Comment by kbr [ 20/Feb/07 ]

Incorporated suggested fix. Thanks for the code. In the future, it would make it
a lot easier if you would use as the source file the exact file from CVS without
reformatting, or provide before-and-after files, or diffs.

Any chance you would consider trying to modify the TextureIO classes to use this
new code path? It might require some significant changes, but would be useful to
the community.





[JOGL-275] Rendering bugs in TextRenderer Created: 21/Feb/07  Updated: 21/Feb/07  Resolved: 21/Feb/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=15937.0


Attachments: Java Source File JoglLabelTest.java    
Issuezilla Id: 275

 Description   

User chrtom on the javagaming.org forums has pointed out crashes and rendering
bugs with the TextRenderer under certain circumstances. The attached test case
demonstrates the problem. It uses a TextRenderer for exactly one rendering
operation, and as soon as the text is too large to fit in the initial backing
store the rendered text starts showing up as a solid rectangle.



 Comments   
Comment by kbr [ 21/Feb/07 ]

Created an attachment (id=91)
Test case

Comment by kbr [ 21/Feb/07 ]

Fixed problem where during resizing of backing store for TextRenderer we were
neglecting to unbind the old texture and bind the new one. This caused attempts
to render with an invalid texture, which was probably the cause of crashes and
definitely the cause of rendering artifacts. Fixed by calling endRendering() /
beginRendering() appropriately on the underlying TextureRenderer during resizing
of the backing store of the TextRenderer.





[JOGL-276] Bug in handling of RGB-like custom BufferedImages in TextureIO Created: 22/Feb/07  Updated: 22/Feb/07  Resolved: 22/Feb/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=15966.0


Attachments: Java Source File Lesson06.java     PNG File NeHe.png    
Issuezilla Id: 276

 Description   

The code path which handles RGB-like TYPE_CUSTOM BufferedImages in the TextureIO
classes is computing the row length incorrectly. It should be dividing the
scanline stride by 3 instead of 4. This happens most often with PNG images.



 Comments   
Comment by kbr [ 22/Feb/07 ]

Created an attachment (id=92)
Java source for test case

Comment by kbr [ 22/Feb/07 ]

Created an attachment (id=93)
Image for test case

Comment by kbr [ 22/Feb/07 ]

Code path handling RGB-like TYPE_CUSTOM BufferedImages in the TextureIO classes
should have been computing the row length by dividing the scanline stride by 3,
not 4.





[JOGL-277] Documentation enhancement Created: 23/Feb/07  Updated: 27/Feb/07  Resolved: 27/Feb/07

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

Type: Improvement Priority: Major
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: All
Platform: All
URL: http://download.java.net/media/jogl/builds/nightly/javadoc_public/com/sun/opengl/util/Screenshot.html


Issuezilla Id: 277

 Description   

The screenshot utility classes do not specify from which buffer it will read.
More specifically it needs to mention that whatever the last assigned read
buffer from a call to glReadBuffer is the buffer for which a screenshot is made.

If no call has been made, then the OpenGL rules apply: the OpenGL default buffer
is initially GL_FRONT in single-buffered configurations, and GL_BACK in
double-buffered configurations.

Another option may be to add another method which accepts from which buffer to
read.



 Comments   
Comment by kbr [ 27/Feb/07 ]

Added text to Screenshot class's methods indicating which read buffer is used.





[JOGL-278] Fatal error when rendering text Created: 23/Feb/07  Updated: 27/Feb/07  Resolved: 27/Feb/07

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

Type: Bug Priority: Major
Reporter: chrtom 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: 278

 Description   

Problems occur when rendering frequently changing labels that
are rather large in terms of font size and in terms of string length.
I was able to reproduce this problem with the attached test case,
where labels are randomly drawn, disappear, or appear as solid
rectangles.
Hardware: AMD Athlon 1.8 MHz, 1GB RAM, ATI Radeon 9600 Pro, Windows XP
Software: JDK 6, JOGL 1.1 rc3



 Comments   
Comment by chrtom [ 23/Feb/07 ]

Go to: www.informatik.uni-rostock.de/~ct/testCase.zip for
screen shots and test case. See also the jogl forum at
http://www.javagaming.org/forums/index.php?topic=15937.0

Comment by kbr [ 27/Feb/07 ]

Added code to restore current text drawing color when backing store is resized.
Fixed NullPointerException in RectanglePacker during deletion if no backing
store was allocated.





[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-270] Possible issues with GLJPanel / pbuffers on X11 Created: 12/Feb/07  Updated: 12/Feb/07  Resolved: 12/Feb/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: 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: 270

 Description   

The thread http://www.javagaming.org/forums/index.php?topic=15866.0 indicates
there may be issues with the latest JOGL builds and NVidia's drivers on X11
platforms when using a context created on a pbuffer to query the available
extensions. Need to find an appropriately-configured machine to test on.



 Comments   
Comment by kbr [ 12/Feb/07 ]

This was confirmed by the submitter as a mismatch between versions of jogl.jar
and gluegen-rt.jar.





[JOGL-266] Loading TGA out of a jar using getResourceAsStream shows a corrupted Texture Created: 23/Jan/07  Updated: 26/Jan/07  Resolved: 26/Jan/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: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC
URL: http://www.embege.com/misc/Test.jar


Attachments: Java Archive File Test.jar    
Issuezilla Id: 266

 Description   

hello,

when loading a tga texture from inside a jar, using getResourceAsStream, the
texture seems to be cut off at the top. when running the same program directly,
the texture displays correctly.

i have attached a jar, which includes the texture and the source. you should be
able to run the jar in a directory with the jogl.jar and the native libraries.

see also:
http://www.javagaming.org/forums/index.php?topic=15731.0

you can contact me on the javagaming forum user emzic or via email: emzic at
embege dot com



 Comments   
Comment by emzic [ 23/Jan/07 ]

Created an attachment (id=89)
Testcase. run the jar in a directory with jogl.jar and the natives.

Comment by kbr [ 26/Jan/07 ]

I see no difference in behavior of the test case when reading the texture using
getResourceAsStream() vs. reading from a FileInputStream.

You shouldn't be ignoring the return value from InputStream.read(). You should
also be wrapping the InputStream in a BufferedInputStream. See
com.sun.opengl.util.StreamUtil.readAll().

This isn't a JOGL bug. Closing it as not a bug.





[JOGL-262] DRIHack problems with ATI and possibly other drivers Created: 20/Jan/07  Updated: 20/Jan/07  Resolved: 20/Jan/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: 262

 Description   

Dave Collins from the WW collaborative research project reported that JOGL is
not picking up ATI's hardware-accelerated drivers. Other users have reported
problems even with NVidia's drivers on recent Linux distributions: see
http://www.javagaming.org/forums/index.php?topic=15610.0 . Experimentation has
shown that attempting to dlopen() libGL.so via GlueGen's NativeLibrary class
ends up picking up Mesa's drivers, but dlopen()ing libGL.so.1 explicitly picks
up the correct drivers. Unclear exactly why this is, but changes need to be made
to support this usage mode in the NativeLibrary run-time class.



 Comments   
Comment by kbr [ 20/Jan/07 ]

Added support to GlueGen's NativeLibrary class for relative library
path names which do not require expansion; for example, "libGL.so.1".
Changed the DRIHack to first attempt to open libGL.so.1 instead of
"GL", which expanded to "libGL.so". For some reason, this causes ATI's
drivers to be picked up properly. Tested with various JOGL demos.





[JOGL-264] SecurityException in JOGLAppletLauncher if JOAL not present Created: 22/Jan/07  Updated: 22/Jan/07  Resolved: 22/Jan/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=15755.0


Issuezilla Id: 264

 Description   

User operator on the javagaming.org forums has indicated that under some
circumstances (presumably if the JOAL classes do not exist on the web server and
it redirects elsewhere) that a SecurityException may be raised when trying to
look up the AL class. Should make the JOGLAppletLauncher more robust to this
situation.



 Comments   
Comment by kbr [ 22/Jan/07 ]

Made JOGLAppletLauncher more robust to exceptions thrown from
Class.forName() looking up AL.class.





[JOGL-269] Flickering on Windows Vista Created: 12/Feb/07  Updated: 13/Feb/07  Resolved: 13/Feb/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


Issuezilla Id: 269

 Description   

The thread http://www.javagaming.org/forums/index.php?topic=15722.0 indicates
there may be JOGL-specific issues on Windows Vista. Need to look into this.



 Comments   
Comment by kbr [ 13/Feb/07 ]

Attempted to install Vista on the only PC we had available which would accept a
Radeon 9800. The network card wasn't detected and apparently USB devices also
didn't work – a USB flash drive didn't work. We do not have the time to look
into this further.





[JOGL-263] JOGL applets slow in Mozilla / Firefox Created: 22/Jan/07  Updated: 22/Jan/07  Resolved: 22/Jan/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=12200.30


Issuezilla Id: 263

 Description   

It has been discovered that the root cause of the slowdown of JOGL applets
running in Mozilla / Firefox is the presence of the Talkback agent. See the
following URL on javagaming.org:
http://www.javagaming.org/forums/index.php?topic=12200.30
and the following URL on the Mozilla bug tracking system:
https://bugzilla.mozilla.org/show_bug.cgi?id=326381



 Comments   
Comment by kbr [ 22/Jan/07 ]

Added documentation to JOGLAppletLauncher indicating that Talkback
agent is responsible for slowdown of JOGL-based applets and provided
instructions on how to turn it off.





[JOGL-271] wglGetPixelFormatAttribivARB() fails forcing software OpenGL Created: 13/Feb/07  Updated: 19/Feb/07  Resolved: 19/Feb/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: PC


Issuezilla Id: 271

 Description   

In in createPbuffer() in WindowsPbufferGLDrawable class there is a query of some
attributes that includes WGLExt.WGL_SAMPLE_BUFFERS and WGLExt.WGL_SAMPLES_ARB.
But if the OpenGL renderer does not support WGL_ARB_multisample, it has already
been determined that it doesn't, the query will fail and jogl assumes that
Pbuffers are not supported.

If the code were modified to ask for multisample related attributes only if the
renderer supported the multisample extension then Pbuffer support would work fine.



 Comments   
Comment by kbr [ 19/Feb/07 ]

New code added for support of getChosenGLCapabilities() was causing these
errors. Conditionalized querying of multisample properties based on availability
of WGL_ARB_multisample extension.

Please try a nightly build dated 2/20 or later and reopen this bug if errors
persist.





[JOGL-267] class DDSImage return incorrect mipmap level data. Created: 24/Jan/07  Updated: 26/Jan/07  Resolved: 26/Jan/07

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

Type: Bug Priority: Major
Reporter: bandures 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: 267

 Description   

class DDSImage return incorrect mipmap level data for lowest mipmaps in case
then image width and height not equal. In that case mipMapHeight or mipMapWidth
can return 0.

To fix problem, in mipMapHeight/mipMapWidth need to make following change:
> return height;
to
> return Math.max( height, 1 );



 Comments   
Comment by kbr [ 26/Jan/07 ]

Thanks for the patch. It's been applied to the JOGL source tree.





[JOGL-265] problem scaling TYPE_INT_ARGB, Alpha not scaling Created: 23/Jan/07  Updated: 24/Jan/07  Resolved: 24/Jan/07

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

Type: Bug Priority: Major
Reporter: krazykatz 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
URL: http://www.kyrondevelopment.com/viewer/JoglScaler.java


Issuezilla Id: 265

 Description   

The following code doesn't work on one of the laptops in our office. The
same problem is showing up on a workstation at one of our site's. It is fine
on 6-8 other computers I've tried it on. The laptop has Window's XP and a
"GeForce Go 7900 GS" card.

All the code is trying to do is scale a 2D image. Scaling greyscale works fine,
but when scaling TYPE_INT_ARGB all transparency is lost. For the complete
source for the class check out the URL
http://www.kyrondevelopment.com/viewer/JoglScaler.java

// Prepare a texture w/ source
gl.glTexSubImage2D(
GL.GL_TEXTURE_2D,
0,
0,
0,
m_src_width,
m_src_height,
GL.GL_RGBA,
GL.GL_UNSIGNED_BYTE,
src_ints );

// Map the source texture to a quad
gl.glBegin( GL.GL_QUADS );
gl.glTexCoord2d( 0.0, 0.0 );
gl.glVertex2f( 0.f, 0.f );

gl.glTexCoord2d( 0.0, m_dst_height/m_scaley/PBUFFER_HEIGHT );
gl.glVertex2f( 0.f, m_dst_height );

gl.glTexCoord2d( m_dst_width/m_scalex/PBUFFER_WIDTH,
m_dst_height/m_scaley/PBUFFER_HEIGHT );
gl.glVertex2f( m_dst_width, m_dst_height );

gl.glTexCoord2d( m_dst_width/m_scalex/PBUFFER_WIDTH, 0.0 );
gl.glVertex2f( m_dst_width, 0.f );
gl.glEnd();

gl.glFlush();

// Retrieve the scaled data
IntBuffer scaled_buffer = BufferUtil.newIntBuffer(PBUFFER_SIZE);
gl.glReadPixels(
0,
0,
m_dst_width,
m_dst_height,
GL.GL_RGBA,
GL.GL_UNSIGNED_INT_8_8_8_8_REV,
scaled_buffer );

int[] dst_ints = ((DataBufferInt)m_dst.getRaster().getDataBuffer()).
getData();



 Comments   
Comment by kbr [ 23/Jan/07 ]

I suspect you need to call setAlphaBits(8) on the GLCapabilities you use to
create your GLPbuffer. If this doesn't solve the problem then please provide a
complete and self-contained test case showing the issue. I'll leave this bug
open for another day or two, but I don't believe this is a JOGL bug.

Comment by krazykatz [ 24/Jan/07 ]

Thank you that seems to be it.

Comment by kbr [ 24/Jan/07 ]

Not a JOGL bug.





[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-259] need a copy context Created: 18/Dec/06  Updated: 07/Jan/07  Resolved: 07/Jan/07

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

Type: Improvement 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: 259

 Description   

Why is there no copy method on a GLContext? It is availavable in all of the
supported native platforms. There is a wglCopyContext() in WGL, a
glXCopyContext() in GLX, and an aglCopyContext in AGL for OSX. Are there plans
to add it?

This is from Topic: no copy context



 Comments   
Comment by kbr [ 07/Jan/07 ]

URL to forum posting:

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

Comment by kbr [ 07/Jan/07 ]

Added and specified GLContext.copy() and supplied implementations on
Windows, X11 and Mac OS X platforms. New code is untested at this
time.





[JOGL-257] RFE: Texture.updateSubImage(x,y,w,h) Created: 07/Dec/06  Updated: 29/Dec/06  Resolved: 29/Dec/06

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

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

Operating System: All
Platform: All


Issuezilla Id: 257

 Description   

I've seen a couple requests recently for a Texture.updateSubImage(x,y,w,h) method, see the comments
here:
http://weblogs.java.net/blog/campbell/archive/2006/10/easy_2d3d_mixin.html

One person had a go at it, but it's not a complete solution:
http://ochafik.free.fr/blog/?p=87

This method would be useful for those cases where you're trying to keep a various regions of a
BufferedImage in sync with a Texture object. Imagine you have a 500x500 BufferedImage, and you only
want to update a small portion of the texture each time around. Today you have two choices: 1) use
updateImage(), but this will update the entire image each time, or 2) use updateSubImage(), but the x/y
parameters are only for the destination, so you'd have to use BufferedImage.getSubimage() to position
the source correctly, which isn't the most performant solution (would require creating a new
BufferedImage object for each update).

So the new method might look like this:
public void updateSubImage(TextureData data, int mipmapLevel,
int dstx, int dsty, int srcx, int srcy,
int width, int height);

But I see now that this might require lots of changes, e.g. we'd probably need something like
TextureData.getBuffer(int x, int y). Any thoughts on whether this would be worth pursuing (or whether
it's possible without tearing the world apart)?



 Comments   
Comment by campbell [ 07/Dec/06 ]

Maybe we wouldn't need a TextureData.getBuffer(x,y) method after all. It could be as simple as:
glPixelStorei(GL_UNPACK_SKIP_PIXELS, srcx);
glPixelStorei(GL_UNPACK_SKIP_ROWS, srcy);
glPixelStorei(GL_UNPACK_ROW_LENGTH, textureData.getWidth());
glPixelStorei(GL_UNPACK_ALIGNMENT, textureData.getAlignment());

The only question mark is about GL_UNPACK_ROW_LENGTH, since BufferedImages can (in theory, but
not commonly) have extra padding at the end of scanlines, so you'd need something like this instead (if
these methods actually existed on TextureData):
glPixelStorei(GL_UNPACK_ROW_LENGTH,
textureData.getScanlineStride() / textureData.getPixelStride());

We may need to restrict this stuff to non-compressed and non-mipmapped textures only.

Comment by kbr [ 29/Dec/06 ]

Changed TextureIO's BufferedImage code paths to no longer copy the
data in order to correct for the vertical flip needed between Java
2D's and OpenGL's coordinate systems, but instead to correct for this
using a flip of the texture coordinates. This was needed to change the
semantics for the BufferedImage from "by-copy" to "by-reference". Made
the custom BufferedImage copying code path occur lazily upon a call to
TextureData.getBuffer(). Added support for the GL_EXT_abgr extension
but disabled the code path currently as it appears there may be bugs
in its support on some drivers. Added computation of row width for all
BufferedImage types with help and suggestions from Chris Campbell.
Improved handling of some BufferedImage types like TYPE_INT_ARGB and
TYPE_4BYTE_ABGR. Added Texture.updateSubImage() taking a source
rectangle as well as a destination coordinate. Wrote TestSubImage test
to show use of the new API which exercises all BufferedImage types.





[JOGL-256] Bad call to JOAL's NativeLibLoader.disableLoading in JOGLAppletLauncher Created: 05/Dec/06  Updated: 05/Dec/06  Resolved: 05/Dec/06

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

Type: Bug Priority: Major
Reporter: agrv 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: 256

 Description   

The JOGLAppletLauncher class calls net.java.games.joal.impl.NativeLibLoader
instead of net.java.games.joal.NativeLibLoader on line 864 from
JOGLAppletLauncher.java, causing the following ClassNotFoundException when
trying to use JOAL with JOGL in an applet context.

java.lang.ClassNotFoundException: net.java.games.joal.impl.NativeLibLoader
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.sun.opengl.util.JOGLAppletLauncher$6.run(JOGLAppletLauncher.java:864)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)



 Comments   
Comment by kbr [ 05/Dec/06 ]

Sorry about that. I had too much logging information enabled in the Java Plug-In
when I tested this and this exception got lost in the noise. The JOAL
NativeLibLoader has been moved to the net.java.games.joal.impl package and made
public. We'll announce the support for this publicly soon; please let us know if
you see further issues.





[JOGL-260] "GLException: Surface already locked" after failed makeCurrent Created: 17/Jan/07  Updated: 20/Jan/07  Resolved: 20/Jan/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=15709.0


Issuezilla Id: 260

 Description   

The above forum posting, as well as some others from earlier releases of JOGL,
shows that when a makeCurrent() call for an on-screen GLContext fails, the
system starts producing "surface already locked" errors on subsequent calls to
makeCurrent().



 Comments   
Comment by kbr [ 17/Jan/07 ]

Fixed Issue 260: "GLException: Surface already locked" after failed makeCurrent

Added checking for thrown run-time exceptions to on-screen GLContext
makeCurrent() implementations on all three major supported platforms; now
unlocks the underlying GLDrawable if an exception is thrown.

Comment by kbr [ 20/Jan/07 ]

Fixed as described above.





[JOGL-255] Add utility class for using Java2D fonts in JOGL Created: 30/Nov/06  Updated: 20/Jan/07  Resolved: 20/Jan/07

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

Type: Improvement Priority: Major
Reporter: ophir 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: 255

 Description   

Being able to choose any available font, instead of just the GLUT bitmat fonts,
would be wonderfully useful. It sounds like this may be on the way, but if
there is a place for people to vote for it, it may happen sooner.



 Comments   
Comment by ophir [ 30/Nov/06 ]

Now that I look more closely, this is included in issue 157.

Comment by kbr [ 01/Dec/06 ]

We're working on supporting this in the near future. Since the other bug
principally focuses on stroked and extruded fonts, will use this one to track
the issue of supporting Java2D bitmapped fonts.

Comment by kbr [ 20/Jan/07 ]

This has been addressed with the inclusion of the new TextRenderer. See the
associated demos in the jogl-demos workspace under demos.j2d.*.





[JOGL-249] Adding generated sources like GL.java to source distribution Created: 02/Nov/06  Updated: 14/Nov/06  Resolved: 14/Nov/06

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

Type: New Feature Priority: Major
Reporter: olli73 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: 249

 Description   

When I add the JOGL sources to my project in Eclipse or Netbeans, I have no
parameter names in the auto-completion for methods of the GL.class because
GL.java is generated source and not included in the source distribution. But
generating GL.java is a very complex build process.

So, the GL.java should be included in source distribution in a folder like
gen-src or so.



 Comments   
Comment by kbr [ 14/Nov/06 ]

Fixed Issue 249: Adding generated sources like GL.java to source distribution
Fixed Issue 227: Distinct naming for different versions of jogl
Fixed [No Issue Number]: Produce zip bundles from dist target

This set of build.xml changes addresses the issues listed above. The
"dist" target now puts the generated sources like GL.java into the
source archive it produces; it expects that these sources are copied
over from the Linux build. The kind of zip bundles that were produced
for JSR-231 1.0.0 are now the primary result from the "dist" target.
As these zip archives have unique version numbers, I believe these
changes also fix Issue 227, although it could probably be argued the
other way; please reopen this bug if the current changes are not
sufficient. These changes will take effect once the nightly build
machines are back on-line (they are currently being moved) and the
build scripts have been updated.





[JOGL-248] GLJPanel crashes Created: 24/Oct/06  Updated: 01/Dec/06  Resolved: 01/Dec/06

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

Type: Bug Priority: Major
Reporter: tomas_hamala 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: 248

 Description   

Our program uses GLJPanel. This works well on most computers (Windows, Linux and
MacOS X). However, on at least one computer this fails with an exception:
javax.media.opengl.GLException: Error releasing pbuffer device context: error code 0

The top of the stacktrace is as follows:
com.sun.opengl.impl.windows.WindowsPbufferGLDrawable.destroy(WindowsPbufferGLDrawable.java:92)
com.sun.opengl.impl.GLPbufferImpl$DestroyAction.run(GLPbufferImpl.java:253)
com.sun.opengl.impl.GLPbufferImpl.destroy(GLPbufferImpl.java:179)
...

Running in debug mode (-Djogl.debug) the output immediatly preceding the crash is:
Created pbuffer 256 x 256
AWT-EventQueue-1: !!! Destroyed OpenGL context 0x20000
GLJPanel.handleReshape: (w,h) = (437,807)
Resizing pbuffer from (256, 256) to fit (437, 807)

The computer in question runs an AMD Sempron 3000+ on an ASRock K7S41GX
motherboard with an SiS chipset (and onboard GPU). I tried updating the graphics
drivers to the latest version, but it didn't change anything.

This behaviour goes for the demos on https://jogl-demos.dev.java.net/ too:
The demos that use GLCanvas work fine, while the ones with GLJPanel just crash
without any feedback. For example Gears works, but selecting Gears in JRefract
causes the demo to crash.



 Comments   
Comment by tomas_hamala [ 25/Oct/06 ]

Below is a minimal test case. If you run it without parameters (on the mentioned
computer) it crashes when the window is resized. If you run it with a parameter
(meaning JCanvas is used), it doesn't crash.

import javax.swing.JFrame;
import javax.media.opengl.GLJPanel;
import javax.media.opengl.GLCanvas;
import java.awt.Dimension;

public class TestGLJPanel extends JFrame {
private TestGLJPanel(final boolean useCanvas) {
super();
if(useCanvas)

{ System.out.println("Using GLCanvas"); add(new GLCanvas()); }

else

{ System.out.println("Using GLJPanel"); add(new GLJPanel()); }

setSize(new Dimension(250,250));
setVisible(true);
setDefaultCloseOperation(EXIT_ON_CLOSE);
}

public static void main(final String[] args)

{ new TestGLJPanel(args.length>0); }

}

Comment by kbr [ 25/Oct/06 ]

I'm sorry, but I can't reproduce this problem. It is pretty clearly a problem
with the SiS OpenGL drivers, which we have found from experience and users'
reports to be very poor in quality. I don't have a good recommendation aside
from either trying to file a bug with the vendor or to upgrade to a computer
with a better chipset (at least ATI, but NVidia recommended). You may also want
to try using LWJGL to see if you get any better behavior out of that library. If
you do, please reopen this bug and provide the LWJGL test case as well.

Comment by tomas_hamala [ 26/Oct/06 ]

Lwjgl isn't really an option as it, as far as I can see, only offers an AWT
Canvas (which already works in jogl) and not a swing JPanel. So testing that
wouldn't give any more information.

Upgrading the computer is not really a good option either, because we'd rather
not force our customers to upgrade their hardware unless it's really necessary.

I found out that this works if you run jogl without hardware acceleration, by
specifying -Djogl.gljpanel.nohw. If it was possible to do this in the program it
would be great, because then we could just catch any GLException and recreate
the offending JPanel without hardware acceleration.
(Just setting setHardwareAccelerated(false) on GLCapabilities does nothing,
hardware acceleration seems to always be preferred.)

Finally, the documentation for GLJPanel says "This component attempts to use
hardware-accelerated rendering via pbuffers and falls back on to software
rendering if problems occur." So even if it is the SiS drivers that are to
blame, GLJPanel should really handle this better, in my opinion.

Comment by kbr [ 26/Oct/06 ]

Good points. It has been so long since I've diagnosed a problem that I'd
forgotten about the option to use Windows DIB sections rather than pbuffers.
I've reopened this issue and will try to implement the fallback path you've
described soon.

Comment by kbr [ 14/Nov/06 ]

A workaround for the reported issue has been added to the GLJPanel
class and tested by forcing GLPbuffer.destroy() to throw a
GLException. The new fallback path appears to be working correctly.
Please reopen this issue or file a new one if this doesn't appear to
be the case.

The fix is in the JOGL source tree and will be in nightly builds dated 11/15 or
later; note that the nightly builds will be down for a few days due to the
machines being moved.

Comment by tomas_hamala [ 30/Nov/06 ]

Well, I tested it now, and it seems there's still a problem. It does not crash
anymore, but instead it renders a completely black panel. I get this behaviour
both from our program, the jogl demos which use GLJPanel, as well as the above
test program (to which I just added a GLEventListener which renders a quad.)

I'm unsure of how I could test this further. Debugging the program shows that
the display method of the GLEventListener is being called, but for some reason
the results do not show up on screen.

If there are any other tests I could make to help resolve this, please tell me.
Otherwise, I suppose a black window is better than an exception

Comment by tomas_hamala [ 30/Nov/06 ]

Sorry, it seems someone has tried to fix the problem on this computer by
installing new graphics drivers. When I reverted to the correct ones (the ones I
used last time I tested), it started working.

So thanks for the help, and sorry for reopening this again

Comment by kbr [ 01/Dec/06 ]

Marking as fixed again per submitter's feedback.





[JOGL-247] Texture class should use GL_CLAMP if OpenGL version is 1.1 Created: 20/Sep/06  Updated: 14/Nov/06  Resolved: 14/Nov/06

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=14923.0


Issuezilla Id: 247

 Description   

The Texture class should use the GL_CLAMP enumerated value instead of the
GL_CLAMP_TO_EDGE value if the OpenGL version available is less than 1.2. See
http://www.javagaming.org/forums/index.php?topic=14923.0 .



 Comments   
Comment by kbr [ 14/Nov/06 ]

Changed code to check for presence of OpenGL 1.2 and use GL_CLAMP
instead of GL_CLAMP_TO_EDGE if not available.





[JOGL-245] glutSolidCylinder missing from com.sun.opengl.util.GLUT Created: 26/Aug/06  Updated: 13/Nov/06  Resolved: 13/Nov/06

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

Type: Bug Priority: Major
Reporter: profaronnax 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 Source File GLUT.java    
Issuezilla Id: 245

 Description   

The GLUT class is missing bindings for glutSolidCylinder and glutWireCylinder.



 Comments   
Comment by kbr [ 27/Aug/06 ]

It looks like this and some other geometric entry points were added in OpenGLUT.
JOGL's GLUT class was ported from GLUT 3.7.6. We should consider porting the
additional entry points. BTW, the submitter should feel free to contribute a
port of this and other methods.

Comment by profaronnax [ 28/Aug/06 ]

Should glutSolidCylinder draw end caps?

Comment by kbr [ 28/Aug/06 ]

I'd recommend looking at the OpenGLUT source code for guidance here.

Comment by profaronnax [ 01/Sep/06 ]

I have this fixed and ready to commit on my computer. How do I get modify permission for the CVS
repository?

Comment by kbr [ 02/Sep/06 ]

Please attach the diffs and/or the revised files to the bug report and we'll
review and commit them. We only grant write access to the CVS repository to
developers who have made substantial contributions over time. If you wanted to
bring the GLUT implementation up-to-date with respect to OpenGLUT (i.e., adding
the other geometric primitives like glutSolidRhombicDodecahedron) I'd consider
that a substantial contribution.

Comment by profaronnax [ 02/Sep/06 ]

Created an attachment (id=85)
new GLUT class with glutSolidCylinder, glutWireCylinder, glutSolidRhombicDodecahedron, and glutWireRhombicDodecahedron

Comment by profaronnax [ 02/Sep/06 ]

I just posted a copy of GLUT.java with a few more methods from OpenGLUT.

Comment by kbr [ 13/Nov/06 ]

Sorry for the long delay in getting back to this. Thanks for your suggested
changes; they've been incorporated into the source tree and will show up in
tomorrow's nightly build as well as in a future release of the JSR-231 RI.





[JOGL-244] Using gl.glColor3f and gl.glColor4f in same GL block Created: 17/Aug/06  Updated: 24/Aug/06  Resolved: 24/Aug/06

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

Type: Bug Priority: Major
Reporter: spark343 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: Mac OS X
Platform: Macintosh


Issuezilla Id: 244

 Description   

On my platform, Mac OS X 10.4.7, Java 1.5.0_6, JOGL library JSR-231 Beta 05,
JOGL will cause my code to crash (no error, or trace) when using gl.glColor3f()
and gl.glColor4f() in the same gl.glBegin(GL.GL_QUADS) -> gl.glEnd() code block.
Placing the calls to gl.glColor3f()

I have tested the same code on the Windows platform and it does not have this
issue, it appears to be Mac specific.



 Comments   
Comment by kbr [ 24/Aug/06 ]

There is basically zero chance that this is a bug in JOGL. The autogenerated
code for glColor3f / glColor4f is trivial, provably correct by inspection, and
has been extremely well tested in many applications. If you can produce a small
and self-contained test case reproducing the problem I'd recommend you post it
on the forums for help, or if you still believe it's a bug in JOGL you can feel
free to reopen this bug report. In the meantime I'm closing it as "works for me".





[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-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-239] Cannot build jogl on FreeBSD Created: 18/Jul/06  Updated: 18/Jul/06  Resolved: 18/Jul/06

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

Type: Bug Priority: Major
Reporter: cybasheep 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: FreeBSD
Platform: Other


Issuezilla Id: 239

 Description   

I am trying to build jogl 1.0.0-beta5 on FreeBSD 5.5 with a native JDK 1.5.0,
ant 1.6.5 and antlr 2.7.5.

I've followed the build instructions to the best of my ability, but the build
fails in the c.build stage. I've included the complete buildlog below. Any
suggestions would be very much appreciated.

Thanks,

Michael Nottebrock (lofi@freebsd.org)

[lofi@kiste]:0:~/foobar/jogl/make > ant
Buildfile: build.xml

gluegen.cpptasks.detect.os:
[echo] FreeBSD=true
[echo] HPUX=$

{isHPUX}

[echo] IA64=$

{isIA64}

[echo] Linux=$

{isLinux}

[echo] LinuxAMD64=$

{isLinuxAMD64}

[echo] LinuxIA64=$

{isLinuxIA64}

[echo] LinuxX86=$

{isLinuxX86}

[echo] OS X=$

{isOSX}

[echo] Solaris=$

{isSolaris}

[echo] SolarisSparcv9=$

{isSolarisSparcv9}

[echo] Unix=true
[echo] Windows=$

{isWindows}

[echo] X11=true

base.init:

base.init.sourcelevel.1:

base.init.sourcelevel.2:

load.user.properties:
[echo] Loaded /home/lofi/jogl.properties.
[echo] Loaded /home/lofi/gluegen.properties.
[echo] antlr.jar=/usr/local/share/java/classes/antlr.jar

setup.java.home.dir.nonmacosx:

setup.java.home.dir.macosx:

setup.java.home.dir:

gluegen.cpptasks.detect.compiler:
[echo] VC6=$

{isVC6}
[echo] VC7=${isVC7}
[echo] VC8=${isVC8}
[echo] MingW=${isMingW}

declare.common:

init:

antlr.jar.validate:

java.home.dir.validate:

java.class.path.validate:

validate:
[mkdir] Created dir: /usr/home/lofi/foobar/jogl/build/gensrc/classes
[mkdir] Created dir: /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl
[mkdir] Created dir: /usr/home/lofi/foobar/jogl/build/classes
[mkdir] Created dir: /usr/home/lofi/foobar/jogl/build/obj
[mkdir] Created dir: /usr/home/lofi/foobar/jogl/build/obj/jogl
[mkdir] Created dir: /usr/home/lofi/foobar/jogl/build/obj/jogl_cg

declare.win32.vc6:

declare.win32.vc7:

declare.win32.vc8:

declare.win32.vc8_x64:

declare.win32.mingw:

declare.win32:

declare.linux.x86:

declare.linux.amd64:

declare.linux.ia64:

declare.x11:

declare.linux:

declare.solaris:

declare.solarisSparcv9:

declare.macosx:

declare.freebsd:
[echo] FreeBSD

declare.hpux:

declare:

all:

gluegen.cpptasks.detect.os:

base.init:

base.init.sourcelevel.1:

base.init.sourcelevel.2:

load.user.properties:

setup.java.home.dir.nonmacosx:

setup.java.home.dir.macosx:

setup.java.home.dir:

gluegen.cpptasks.detect.compiler:
[echo] VC6=${isVC6}

[echo] VC7=$

{isVC7}

[echo] VC8=$

{isVC8}

[echo] MingW=$

{isMingW}

declare.common:

init:

antlr.jar.validate:

java.home.dir.validate:

java.class.path.validate:

validate:

build.gluegen:

load.user.properties:
[echo] Loaded /home/lofi/gluegen.properties.
[echo] antlr.jar=/usr/local/share/java/classes/antlr.jar

setup-excludes-1:

setup-excludes-2:

init:

antlr.jar.validate:

java.class.path.validate:

validate:
[mkdir] Created dir: /usr/home/lofi/foobar/gluegen/build/gensrc/java
[mkdir] Created dir: /usr/home/lofi/foobar/gluegen/build/classes

gluegen.build:
[mkdir] Created
dir: /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram
[copy] Copying 5 files
to /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram

generate.c.grammar:
[antlr] ANTLR Parser Generator Version 2.7.5 (20050128) 1989-2005
jGuru.com

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:232:
warning:nondeterminism between alts 1 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:232:
k==1:"struct"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:232:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:232:
warning:nondeterminism between alts 2 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:232:
k==1:"union"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:232:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:232:
warning:nondeterminism between alts 3 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:232:
k==1:"enum"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:232:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:331:
warning:nondeterminism between alts 1 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:331:
k==1:"struct"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:331:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:331:
warning:nondeterminism between alts 2 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:331:
k==1:"union"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:331:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:331:
warning:nondeterminism between alts 3 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:331:
k==1:"enum"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:331:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:346:17:
warning:Rule 'declarator' returns a value

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:526:
warning:nondeterminism between alts 1 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:526:
k==1:"struct"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:526:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:526:
warning:nondeterminism between alts 2 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:526:
k==1:"union"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:526:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:526:
warning:nondeterminism between alts 3 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:526:
k==1:"enum"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:526:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:536:
warning:Syntactic predicate superfluous for single alternative

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1084:
warning:lexical nondeterminism between alts 2 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1084:
k==1:'\r'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1084:
k==2:'\n'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1084:
k==3:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1114:9:
warning:lexical nondeterminism between alts 2 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1114:9:
k==1:'\t','\u000c',' ','d'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1114:9:
k==2:'\t','\u000c',' ','d','e'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1114:9:
k==3:'\t','\u000c',' ','d'..'f'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1115:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1115:
k==1:'\t','\u000c',' '

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1115:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1115:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1115:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1115:54:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1115:54:
k==1:'.','0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1115:54:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1115:54:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1148:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1148:
k==1:'\t','\u000c',' '

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1148:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1148:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1148:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1149:9:
warning:lexical nondeterminism between alts 1 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1149:9:
k==1:'"'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1149:9:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1149:9:
k==3:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1149:9:
warning:lexical nondeterminism between alts 2 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1149:9:
k==1:'A'..'Z','_','a'..'z'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1149:9:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1149:9:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1156:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1156:
k==1:'\t','\u000c',' '

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1156:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1156:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1156:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1157:9:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1157:9:
k==1:'1'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1157:9:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1157:9:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1158:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1158:
k==1:'\t','\u000c',' '

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1158:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1158:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1158:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1159:9:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1159:9:
k==1:'2'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1159:9:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1159:9:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1160:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1160:
k==1:'\t','\u000c',' '

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1160:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1160:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1160:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1161:9:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1161:9:
k==1:'3'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1161:9:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1161:9:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1162:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1162:
k==1:'\t','\u000c',' '

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1162:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1162:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1162:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1163:9:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1163:9:
k==1:'4'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1163:9:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1163:9:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
k==1:'a'..'z'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
k==1:'A'..'Z'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
between alt 2 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
k==1:'_'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
between alt 3 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1372:
between alt 4 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1329:
warning:lexical nondeterminism between alts 4 and 6 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1329:
k==1:'0'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1329:
k==2:'X','x'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1329:
k==3:'0'..'9','A'..'F','a'..'f'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
k==1:'a'..'f'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
k==1:'A'..'F'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
between alt 2 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1358:
between alt 3 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1360:17:
warning:lexical nondeterminism between alts 1 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1360:17:
k==1:'L','l'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1360:17:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1360:17:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1360:17:
warning:lexical nondeterminism between alts 2 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1360:17:
k==1:'U','u'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1360:17:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1360:17:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1331:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1331:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1331:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1331:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1331:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1331:34:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1331:34:
k==1:'E','e'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1331:34:
k==2:'+','-','0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1331:34:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1334:17:
warning:lexical nondeterminism between alts 1 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1334:17:
k==1:'F','f'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1334:17:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1334:17:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1334:17:
warning:lexical nondeterminism between alts 2 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1334:17:
k==1:'L','l'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1334:17:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1334:17:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1341:17:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1341:17:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1341:17:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1341:17:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1341:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1341:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1341:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1341:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1341:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1341:30:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1341:30:
k==1:'E','e'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1341:30:
k==2:'+','-','0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1341:30:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1343:19:
warning:lexical nondeterminism between alts 1 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1343:19:
k==1:'F','f'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1343:19:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1343:19:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1343:19:
warning:lexical nondeterminism between alts 2 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1343:19:
k==1:'L','l'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1343:19:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1343:19:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1348:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1348:
k==1:'0'..'7'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1348:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1348:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1348:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1349:17:
warning:lexical nondeterminism between alts 1 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1349:17:
k==1:'L','l'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1349:17:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1349:17:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1349:17:
warning:lexical nondeterminism between alts 2 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1349:17:
k==1:'U','u'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1349:17:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1349:17:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1353:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1353:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1353:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1353:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1353:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1354:17:
warning:lexical nondeterminism between alts 1 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1354:17:
k==1:'L','l'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1354:17:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1354:17:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1354:17:
warning:lexical nondeterminism between alts 2 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1354:17:
k==1:'U','u'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1354:17:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1354:17:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1197:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1197:
k==1:'
'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1197:
k==2:'"','\'','0'..'7','?','
','a','b','f','n','r','t','v','x'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1197:
k==3:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1286:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1286:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1286:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1286:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/StdCParser.g:1286:
between alt 1 and exit branch of block

generate.c.grammar.glib:
[antlr] ANTLR Parser Generator Version 2.7.5 (20050128) 1989-2005
jGuru.com

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:989:
warning:lexical nondeterminism between alts 4 and 6 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:989:
k==1:'0'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:989:
k==2:'X','x'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:989:
k==3:'0'..'9','A'..'F','a'..'f'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
k==1:'a'..'f'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
k==1:'A'..'F'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
between alt 2 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1013:
between alt 3 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1014:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1014:
k==1:'I','J','L','U','i','j','l','u'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1014:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1014:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1014:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:990:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:990:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:990:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:990:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:990:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:990:34:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:990:34:
k==1:'E','e'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:990:34:
k==2:'+','-','0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:990:34:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:993:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:993:
k==1:'F','I','J','L','U','f','i','j','l','u'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:993:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:993:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:993:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:999:17:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:999:17:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:999:17:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:999:17:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:999:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:999:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:999:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:999:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:999:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:999:30:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:999:30:
k==1:'E','e'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:999:30:
k==2:'+','-','0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:999:30:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1001:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1001:
k==1:'F','I','J','L','U','f','i','j','l','u'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1001:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1001:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1001:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1005:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1005:
k==1:'0'..'7'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1005:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1005:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1005:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1006:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1006:
k==1:'F','I','J','L','U','f','i','j','l','u'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1006:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1006:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1006:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1009:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1009:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1009:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1009:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1009:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1010:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1010:
k==1:'F','I','J','L','U','f','i','j','l','u'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1010:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1010:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1010:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1316:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1316:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1316:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1316:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1316:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==1:'a'..'z'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==1:'A'..'Z'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
between alt 2 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==1:'_'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
between alt 3 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==1:'$'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
between alt 4 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==1:'0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==2:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1035:
between alt 5 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1205:
warning:lexical nondeterminism between alts 2 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1205:
k==1:'\r'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1205:
k==2:'\n'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1205:
k==3:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1231:9:
warning:lexical nondeterminism between alts 2 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1231:9:
k==1:'\t','\u000c',' ','d'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1231:9:
k==2:'\t','\u000c',' ','d','e'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1231:9:
k==3:'\t','\u000c',' ','d'..'f'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1232:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1232:
k==1:'\t','\u000c',' '

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1232:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1232:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1232:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1232:54:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1232:54:
k==1:'.','0'..'9'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1232:54:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1232:54:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1264:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1264:
k==1:'\t','\u000c',' '

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1264:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1264:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1264:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1265:9:
warning:lexical nondeterminism between alts 1 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1265:9:
k==1:'"'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1265:9:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1265:9:
k==3:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1265:9:
warning:lexical nondeterminism between alts 2 and 3 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1265:9:
k==1:'$','A'..'Z','_','a'..'z'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1265:9:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1265:9:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1272:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1272:
k==1:'\t','\u000c',' '

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1272:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1272:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1272:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1273:9:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1273:9:
k==1:'1'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1273:9:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1273:9:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1274:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1274:
k==1:'\t','\u000c',' '

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1274:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1274:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1274:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1275:9:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1275:9:
k==1:'2'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1275:9:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1275:9:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1276:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1276:
k==1:'\t','\u000c',' '

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1276:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1276:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1276:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1277:9:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1277:9:
k==1:'3'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1277:9:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1277:9:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1278:
warning:lexical nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1278:
k==1:'\t','\u000c',' '

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1278:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1278:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1278:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1279:9:
warning:lexical nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1279:9:
k==1:'4'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1279:9:
k==2:'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:1279:9:
k==3:<end-of-token>,'\u0000'..'\u00ff'

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:132:
warning:nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:132:
k==1:SEMI

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:132:
k==2:EOF,"typedef","asm","volatile",SEMI,"struct","union","enum","auto","register","extern","static","const","void","char","short","int","long","float","double","signed","unsigned",ID,STAR,LPAREN,"inline","_int64","typeof","_complex"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:132:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:245:
warning:nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:245:
k==1:SEMI

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:245:
k==2:EOF,"typedef","asm","volatile",LCURLY,RCURLY,SEMI,"struct","union","enum","auto","register","extern","static","const","void","char","short","int","long","float","double","signed","unsigned",ID,STAR,LPAREN,VARARGS,"while","do","for","goto","continue","break","return","case","default","if","switch",LAND,BAND,PLUS,MINUS,INC,DEC,"sizeof",BNOT,LNOT,CharLiteral,StringLiteral,Number,"_label","inline","int64","typeof","complex","alignof","real","_imag"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:245:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:648:
warning:nondeterminism between alts 1 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:648:
k==1:"struct"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:648:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:648:
warning:nondeterminism between alts 2 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:648:
k==1:"union"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:648:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:648:
warning:nondeterminism between alts 3 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:648:
k==1:"enum"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:648:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:158:14:
warning:nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:158:14:
k==1:LCURLY

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:158:14:
k==2:"asm",LCURLY,RCURLY,ID,STAR,LPAREN,LBRACKET,LAND,BAND,PLUS,MINUS,INC,DEC,"sizeof",BNOT,LNOT,DOT,CharLiteral,StringLiteral,Number,"_alignof","real","_imag"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:546:
warning:nondeterminism between alts 1 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:546:
k==1:"struct"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:546:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:546:
warning:nondeterminism between alts 2 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:546:
k==1:"union"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:546:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:546:
warning:nondeterminism between alts 3 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:546:
k==1:"enum"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:546:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:220:17:
warning:nondeterminism between alts 1 and 2 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:220:17:
k==1:COMMA

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:220:17:
k==2:VARARGS

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:236:
warning:nondeterminism upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:236:
k==1:SEMI

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:236:
k==2:"typedef","asm","volatile",LCURLY,RCURLY,SEMI,"struct","union","enum","auto","register","extern","static","const","void","char","short","int","long","float","double","signed","unsigned",ID,STAR,LPAREN,"while","do","for","goto","continue","break","return","case","default","if","switch",LAND,BAND,PLUS,MINUS,INC,DEC,"sizeof",BNOT,LNOT,CharLiteral,StringLiteral,Number,"_label","inline","int64","typeof","complex","alignof","real","_imag"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:236:
between alt 1 and exit branch of block

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:583:
warning:nondeterminism between alts 1 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:583:
k==1:"struct"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:583:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:583:
warning:nondeterminism between alts 2 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:583:
k==1:"union"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:583:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:583:
warning:nondeterminism between alts 3 and 4 of block upon

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:583:
k==1:"enum"

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:583:
k==2:

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedGnuCParser.g:311:21:
warning:Rule 'declarator' returns a value

generate.c.grammar:
[antlr] ANTLR Parser Generator Version 2.7.5 (20050128) 1989-2005
jGuru.com

generate.c.grammar.glib:
[antlr] ANTLR Parser Generator Version 2.7.5 (20050128) 1989-2005
jGuru.com

generate.c.grammar.glib:
[antlr] ANTLR Parser Generator Version 2.7.5 (20050128) 1989-2005
jGuru.com
[antlr] warning: rule HeaderParser.declSpecifiers has different signature
than GnuCTreeParser.declSpecifiers
[antlr] warning: rule HeaderParser.storageClassSpecifier has different
signature than GnuCTreeParser.storageClassSpecifier
[antlr] warning: rule HeaderParser.functionStorageClassSpecifier has
different signature than GnuCTreeParser.functionStorageClassSpecifier
[antlr] warning: rule HeaderParser.typeQualifier has different signature
than GnuCTreeParser.typeQualifier
[antlr] warning: rule HeaderParser.typeSpecifier has different signature
than GnuCTreeParser.typeSpecifier
[antlr] warning: rule HeaderParser.typedefName has different signature
than GnuCTreeParser.typedefName
[antlr] warning: rule HeaderParser.structSpecifier has different signature
than GnuCTreeParser.structSpecifier
[antlr] warning: rule HeaderParser.unionSpecifier has different signature
than GnuCTreeParser.unionSpecifier
[antlr] warning: rule HeaderParser.structOrUnionBody has different
signature than GnuCTreeParser.structOrUnionBody
[antlr] warning: rule HeaderParser.structDeclarationList has different
signature than GnuCTreeParser.structDeclarationList
[antlr] warning: rule HeaderParser.structDeclaration has different
signature than GnuCTreeParser.structDeclaration
[antlr] warning: rule HeaderParser.specifierQualifierList has different
signature than GnuCTreeParser.specifierQualifierList
[antlr] warning: rule HeaderParser.structDeclaratorList has different
signature than GnuCTreeParser.structDeclaratorList
[antlr] warning: rule HeaderParser.structDeclarator has different
signature than GnuCTreeParser.structDeclarator
[antlr] warning: rule HeaderParser.enumSpecifier has different signature
than GnuCTreeParser.enumSpecifier
[antlr] warning: rule HeaderParser.enumList has different signature than
GnuCTreeParser.enumList
[antlr] warning: rule HeaderParser.enumerator has different signature than
GnuCTreeParser.enumerator
[antlr] warning: rule HeaderParser.initDeclList has different signature
than GnuCTreeParser.initDeclList
[antlr] warning: rule HeaderParser.initDecl has different signature than
GnuCTreeParser.initDecl
[antlr] warning: rule HeaderParser.pointerGroup has different signature
than GnuCTreeParser.pointerGroup
[antlr] warning: rule HeaderParser.declarator has different signature than
GnuCTreeParser.declarator
[antlr] warning: rule HeaderParser.parameterTypeList has different
signature than GnuCTreeParser.parameterTypeList
[antlr] warning: rule HeaderParser.parameterDeclaration has different
signature than GnuCTreeParser.parameterDeclaration
[antlr] warning: rule HeaderParser.nonemptyAbstractDeclarator has
different signature than GnuCTreeParser.nonemptyAbstractDeclarator

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedHeaderParser.g:628:27:
warning:Rule 'parameterTypeList' returns a value

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedHeaderParser.g:636:27:
warning:Rule 'parameterTypeList' returns a value

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedHeaderParser.g:373:17:
warning:Rule 'declarator' returns a value

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedHeaderParser.g:612:27:
warning:Rule 'functionStorageClassSpecifier' returns a value

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedHeaderParser.g:613:19:
warning:Rule 'typeQualifier' returns a value

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedHeaderParser.g:614:19:
warning:Rule 'typeSpecifier' returns a value

[antlr] /usr/home/lofi/foobar/gluegen/build/gensrc/java/com/sun/gluegen/cgram/expandedHeaderParser.g:621:2:
warning:Rule 'specifierQualifierList' returns a value
[javac] Compiling 78 source files
to /usr/home/lofi/foobar/gluegen/build/classes
[javac] Note: * uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[jar] Building jar: /usr/home/lofi/foobar/gluegen/build/gluegen.jar
[jar] Building jar: /usr/home/lofi/foobar/gluegen/build/gluegen-rt.jar
[copy] Copying 1 file to /usr/home/lofi/foobar/gluegen/build

all:
[unjar] Expanding: /usr/home/lofi/foobar/gluegen/build/gluegen-rt.jar
into /usr/home/lofi/foobar/jogl/build/classes

java.generate.check:

java.generate:

java.generate.gl:
[echo] Generating GL interface and implementation

java.generate.gl.nsig:
[echo] Generating platform-specific OpenGL extension class
[gluegen] WARNING: skipping emission of unnamed struct "struct
__GLXcontextRec"
[gluegen] WARNING: skipping emission of unnamed struct "struct
__GLXcontextRec"
[gluegen] WARNING: skipping emission of unnamed struct "struct
__GLXcontextRec"
[gluegen] WARNING: skipping emission of unnamed struct "struct
__GLXFBConfigRec"
[gluegen] WARNING: skipping emission of unnamed struct "struct
__GLXFBConfigRec"
[gluegen] WARNING: skipping emission of unnamed struct "struct
__GLXFBConfigRec"
[gluegen] WARNING: skipping emission of unnamed struct "struct { }"
[gluegen] WARNING: skipping emission of unnamed struct "struct { }"
[gluegen] WARNING: skipping emission of unnamed struct "struct { }"
[echo] Generating WGL/GLX/CGL implementation class
[gluegen] WARNING: "GLX_DRAWABLE_TYPE" redefined from "0x8010" to "0x8010"
[gluegen] WARNING: "GLX_WINDOW_BIT" redefined from "0x00000001"
to "0x00000001"
[gluegen] WARNING: "GLX_PIXMAP_BIT" redefined from "0x00000002"
to "0x00000002"
[gluegen] WARNING: "GLX_PBUFFER_BIT" redefined from "0x00000004"
to "0x00000004"
[gluegen] WARNING: "GLX_RGBA_BIT" redefined from "0x00000001"
to "0x00000001"
[gluegen] WARNING: "GLX_COLOR_INDEX_BIT" redefined from "0x00000002"
to "0x00000002"
[gluegen] WARNING: "GLX_PBUFFER_CLOBBER_MASK" redefined from "0x08000000"
to "0x08000000"
[gluegen] WARNING: "GLX_FRONT_LEFT_BUFFER_BIT" redefined from "0x00000001"
to "0x00000001"
[gluegen] WARNING: "GLX_FRONT_RIGHT_BUFFER_BIT" redefined from "0x00000002"
to "0x00000002"
[gluegen] WARNING: "GLX_BACK_LEFT_BUFFER_BIT" redefined from "0x00000004"
to "0x00000004"
[gluegen] WARNING: "GLX_BACK_RIGHT_BUFFER_BIT" redefined from "0x00000008"
to "0x00000008"
[gluegen] WARNING: "GLX_AUX_BUFFERS_BIT" redefined from "0x00000010"
to "0x00000010"
[gluegen] WARNING: "GLX_DEPTH_BUFFER_BIT" redefined from "0x00000020"
to "0x00000020"
[gluegen] WARNING: "GLX_STENCIL_BUFFER_BIT" redefined from "0x00000040"
to "0x00000040"
[gluegen] WARNING: "GLX_ACCUM_BUFFER_BIT" redefined from "0x00000080"
to "0x00000080"
[gluegen] WARNING: "GLX_CONFIG_CAVEAT" redefined from "0x20" to "0x20"
[gluegen] WARNING: "GLX_X_VISUAL_TYPE" redefined from "0x22" to "0x22"
[gluegen] WARNING: "GLX_TRANSPARENT_TYPE" redefined from "0x23" to "0x23"
[gluegen] WARNING: "GLX_TRANSPARENT_INDEX_VALUE" redefined from "0x24"
to "0x24"
[gluegen] WARNING: "GLX_TRANSPARENT_RED_VALUE" redefined from "0x25"
to "0x25"
[gluegen] WARNING: "GLX_TRANSPARENT_GREEN_VALUE" redefined from "0x26"
to "0x26"
[gluegen] WARNING: "GLX_TRANSPARENT_BLUE_VALUE" redefined from "0x27"
to "0x27"
[gluegen] WARNING: "GLX_TRANSPARENT_ALPHA_VALUE" redefined from "0x28"
to "0x28"
[gluegen] WARNING: "GLX_DONT_CARE" redefined from "0xFFFFFFFF"
to "0xFFFFFFFF"
[gluegen] WARNING: "GLX_NONE" redefined from "0x8000" to "0x8000"
[gluegen] WARNING: "GLX_SLOW_CONFIG" redefined from "0x8001" to "0x8001"
[gluegen] WARNING: "GLX_TRUE_COLOR" redefined from "0x8002" to "0x8002"
[gluegen] WARNING: "GLX_DIRECT_COLOR" redefined from "0x8003" to "0x8003"
[gluegen] WARNING: "GLX_PSEUDO_COLOR" redefined from "0x8004" to "0x8004"
[gluegen] WARNING: "GLX_STATIC_COLOR" redefined from "0x8005" to "0x8005"
[gluegen] WARNING: "GLX_GRAY_SCALE" redefined from "0x8006" to "0x8006"
[gluegen] WARNING: "GLX_STATIC_GRAY" redefined from "0x8007" to "0x8007"
[gluegen] WARNING: "GLX_TRANSPARENT_RGB" redefined from "0x8008" to "0x8008"
[gluegen] WARNING: "GLX_TRANSPARENT_INDEX" redefined from "0x8009"
to "0x8009"
[gluegen] WARNING: "GLX_VISUAL_ID" redefined from "0x800B" to "0x800B"
[gluegen] WARNING: "GLX_SCREEN" redefined from "0x800C" to "0x800C"
[gluegen] WARNING: "GLX_NON_CONFORMANT_CONFIG" redefined from "0x800D"
to "0x800D"
[gluegen] WARNING: "GLX_DRAWABLE_TYPE" redefined from "0x8010" to "0x8010"
[gluegen] WARNING: "GLX_RENDER_TYPE" redefined from "0x8011" to "0x8011"
[gluegen] WARNING: "GLX_X_RENDERABLE" redefined from "0x8012" to "0x8012"
[gluegen] WARNING: "GLX_FBCONFIG_ID" redefined from "0x8013" to "0x8013"
[gluegen] WARNING: "GLX_RGBA_TYPE" redefined from "0x8014" to "0x8014"
[gluegen] WARNING: "GLX_COLOR_INDEX_TYPE" redefined from "0x8015"
to "0x8015"
[gluegen] WARNING: "GLX_MAX_PBUFFER_WIDTH" redefined from "0x8016"
to "0x8016"
[gluegen] WARNING: "GLX_MAX_PBUFFER_HEIGHT" redefined from "0x8017"
to "0x8017"
[gluegen] WARNING: "GLX_MAX_PBUFFER_PIXELS" redefined from "0x8018"
to "0x8018"
[gluegen] WARNING: "GLX_PRESERVED_CONTENTS" redefined from "0x801B"
to "0x801B"
[gluegen] WARNING: "GLX_LARGEST_PBUFFER" redefined from "0x801C" to "0x801C"
[gluegen] WARNING: "GLX_WIDTH" redefined from "0x801D" to "0x801D"
[gluegen] WARNING: "GLX_HEIGHT" redefined from "0x801E" to "0x801E"
[gluegen] WARNING: "GLX_EVENT_MASK" redefined from "0x801F" to "0x801F"
[gluegen] WARNING: "GLX_DAMAGED" redefined from "0x8020" to "0x8020"
[gluegen] WARNING: "GLX_SAVED" redefined from "0x8021" to "0x8021"
[gluegen] WARNING: "GLX_WINDOW" redefined from "0x8022" to "0x8022"
[gluegen] WARNING: "GLX_PBUFFER" redefined from "0x8023" to "0x8023"
[gluegen] WARNING: "GLX_PBUFFER_HEIGHT" redefined from "0x8040" to "0x8040"
[gluegen] WARNING: "GLX_PBUFFER_WIDTH" redefined from "0x8041" to "0x8041"
[gluegen] WARNING: "GLX_SAMPLE_BUFFERS" redefined from "0x186a0" to "100000"
[gluegen] WARNING: "GLX_SAMPLES" redefined from "0x186a1" to "100001"
[gluegen] WARNING: skipping emission of unnamed struct "struct
__GLXcontextRec"
[gluegen] WARNING: skipping emission of unnamed struct "struct
__GLXcontextRec"
[gluegen] WARNING: skipping emission of unnamed struct "struct
__GLXcontextRec"
[gluegen] WARNING: skipping emission of unnamed struct "struct
__GLXFBConfigRec"
[gluegen] WARNING: skipping emission of unnamed struct "struct
__GLXFBConfigRec"
[gluegen] WARNING: skipping emission of unnamed struct "struct
__GLXFBConfigRec"
[gluegen] WARNING: Array fields (field "char[80] pipeName;" of
type "GLXHyperpipeConfigSGIX") not implemented yet
[gluegen] WARNING: Array fields (field "char[80] pipeName;" of
type "GLXHyperpipeConfigSGIX") not implemented yet
[gluegen] WARNING: Array fields (field "char[80] pipeName;" of
type "GLXHyperpipeNetworkSGIX") not implemented yet
[gluegen] WARNING: Array fields (field "char[80] pipeName;" of
type "GLXHyperpipeNetworkSGIX") not implemented yet
[gluegen] WARNING: skipping emission of unnamed struct "struct { }"
[gluegen] WARNING: skipping emission of unnamed struct "struct { }"
[gluegen] WARNING: skipping emission of unnamed struct "struct { }"
[gluegen] WARNING: No capacity specified for java.nio.Buffer return value
for function "GLXHyperpipeConfigSGIX dispatch_glXQueryHyperpipeConfigSGIX(long
dpy, int hpId, java.nio.IntBuffer npipes)"; assuming size of equivalent C
return type (sizeof(GLXHyperpipeConfigSGIX *)): GLXHyperpipeConfigSGIX
dispatch_glXQueryHyperpipeConfigSGIX(long dpy, int hpId, java.nio.IntBuffer
npipes)
[gluegen] WARNING: No capacity specified for java.nio.Buffer return value
for function "GLXHyperpipeConfigSGIX dispatch_glXQueryHyperpipeConfigSGIX(long
dpy, int hpId, java.nio.IntBuffer npipes)"; assuming size of equivalent C
return type (sizeof(GLXHyperpipeConfigSGIX *)): GLXHyperpipeConfigSGIX
dispatch_glXQueryHyperpipeConfigSGIX(long dpy, int hpId, java.nio.IntBuffer
npipes)
[gluegen] WARNING: No capacity specified for java.nio.Buffer return value
for function "GLXHyperpipeNetworkSGIX
dispatch_glXQueryHyperpipeNetworkSGIX(long dpy, java.nio.IntBuffer npipes)";
assuming size of equivalent C return type (sizeof(GLXHyperpipeNetworkSGIX *)):
GLXHyperpipeNetworkSGIX dispatch_glXQueryHyperpipeNetworkSGIX(long dpy,
java.nio.IntBuffer npipes)
[gluegen] WARNING: No capacity specified for java.nio.Buffer return value
for function "GLXHyperpipeNetworkSGIX
dispatch_glXQueryHyperpipeNetworkSGIX(long dpy, java.nio.IntBuffer npipes)";
assuming size of equivalent C return type (sizeof(GLXHyperpipeNetworkSGIX *)):
GLXHyperpipeNetworkSGIX dispatch_glXQueryHyperpipeNetworkSGIX(long dpy,
java.nio.IntBuffer npipes)
[echo] Generating JAWT interface class
[echo] java.home.dir=/usr/local/jdk1.5.0/jre/..
Overriding previous definition of reference to stub.includes.fileset.platform
[gluegen] WARNING: Complicated fields (field "JNIEnv * env;" of
type "JAWT_DrawingSurface") not implemented yet
[gluegen] WARNING: Complicated fields (field "jobject target;" of
type "JAWT_DrawingSurface") not implemented yet
[gluegen] WARNING: No capacity specified for java.nio.Buffer return value
for function "JAWT_DrawingSurfaceInfo GetDrawingSurfaceInfo()"; assuming size
of equivalent C return type (sizeof(JAWT_DrawingSurfaceInfo *)):
JAWT_DrawingSurfaceInfo GetDrawingSurfaceInfo()
[gluegen] WARNING: Complicated fields (field "JNIEnv * env;" of
type "JAWT_DrawingSurface") not implemented yet
[gluegen] WARNING: Complicated fields (field "jobject target;" of
type "JAWT_DrawingSurface") not implemented yet
[gluegen] WARNING: Complicated fields (field "JNIEnv * env;" of
type "JAWT_DrawingSurface") not implemented yet
[gluegen] WARNING: Complicated fields (field "jobject target;" of
type "JAWT_DrawingSurface") not implemented yet
[gluegen] WARNING: Complicated fields (field "JAWT_DrawingSurface * ds;" of
type "JAWT_DrawingSurfaceInfo") not implemented yet
[gluegen] WARNING: Complicated fields (field "JAWT_Rectangle * clip;" of
type "JAWT_DrawingSurfaceInfo") not implemented yet
[gluegen] WARNING: Complicated fields (field "JAWT_DrawingSurface * ds;" of
type "JAWT_DrawingSurfaceInfo") not implemented yet
[gluegen] WARNING: Complicated fields (field "JAWT_Rectangle * clip;" of
type "JAWT_DrawingSurfaceInfo") not implemented yet
[gluegen] WARNING: Complicated fields (field "JAWT_DrawingSurface * ds;" of
type "JAWT_DrawingSurfaceInfo") not implemented yet
[gluegen] WARNING: Complicated fields (field "JAWT_Rectangle * clip;" of
type "JAWT_DrawingSurfaceInfo") not implemented yet
[gluegen] WARNING: skipping emission of unnamed struct "struct _jobject"
[gluegen] WARNING: skipping emission of unnamed struct "struct _jobject"
[gluegen] WARNING: skipping emission of unnamed struct "struct _jobject"
[gluegen] WARNING: No capacity specified for java.nio.Buffer return value
for function "JAWT_DrawingSurface GetDrawingSurface(java.lang.Object target)";
assuming size of equivalent C return type (sizeof(JAWT_DrawingSurface *)):
JAWT_DrawingSurface GetDrawingSurface(java.lang.Object target)
[gluegen] WARNING: skipping emission of unnamed struct "struct { }"
[gluegen] WARNING: skipping emission of unnamed struct "struct { }"
[gluegen] WARNING: skipping emission of unnamed struct "struct { }"
[echo] Generating StaticGLInfo class
[echo] Generating GLU class

[echo] GlueGen and BuildStaticGLInfo have successfully generated files.

java.generate.cg.check:

java.generate.cg:

java.compile.firstpass:
[javac] Compiling 1 source file
to /usr/home/lofi/foobar/jogl/build/classes

java.generate.composable.pipeline.check:

java.generate.composable.pipeline:

java.compile.secondpass:
[javac] Compiling 181 source files
to /usr/home/lofi/foobar/jogl/build/classes
[javac] Note: * uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.

java.compile:

check-RIcond:

cond-if-RImanifest:

cond-else-RImanifest:
[copy] Copying 1 file to /usr/home/lofi/foobar/jogl/make
[jar] Building jar: /usr/home/lofi/foobar/jogl/build/jogl.jar
[delete] Deleting: /usr/home/lofi/foobar/jogl/make/tempversion

jar:

c.build.jogl.core:

c.configure:

c.build:
[echo] Output lib name = jogl
[cc] 6 total files to be compiled.
[cc] cc1: warning: command line option "-fno-rtti" is valid for
C+/ObjC+ but not for C
[cc] cc1: warning: command line option "-fno-rtti" is valid for
C+/ObjC+ but not for C
[cc] cc1: warning: command line option "-fno-rtti" is valid for
C+/ObjC+ but not for C
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXChooseFBConfig0__JILjava_lang_Object_2ILjava_lang_Object_2IJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:381:
error: syntax error before "ptr_glXChooseFBConfig"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:395:
error: `ptr_glXChooseFBConfig' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:395:
error: (Each undeclared identifier is reported only once
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:395:
error: for each function it appears in.)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:395:
error: `PFNGLXCHOOSEFBCONFIGPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:395:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXChooseFBConfig1__JILjava_lang_Object_2ILjava_lang_Object_2IJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:416:
error: syntax error before "ptr_glXChooseFBConfig"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:424:
error: `ptr_glXChooseFBConfig' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:424:
error: `PFNGLXCHOOSEFBCONFIGPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:424:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXCreateNewContext0__JLjava_nio_ByteBuffer_2IJZJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:541:
error: syntax error before "ptr_glXCreateNewContext"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:547:
error: `ptr_glXCreateNewContext' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:547:
error: `PFNGLXCREATENEWCONTEXTPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:547:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXCreatePbuffer0__JLjava_nio_ByteBuffer_2Ljava_lang_Object_2IJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:561:
error: syntax error before "ptr_glXCreatePbuffer"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:571:
error: `ptr_glXCreatePbuffer' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:571:
error: `PFNGLXCREATEPBUFFERPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:571:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXCreatePbuffer1__JLjava_nio_ByteBuffer_2Ljava_lang_Object_2IJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:585:
error: syntax error before "ptr_glXCreatePbuffer"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:592:
error: `ptr_glXCreatePbuffer' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:592:
error: `PFNGLXCREATEPBUFFERPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:592:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXCreatePixmap0__JLjava_nio_ByteBuffer_2JLjava_lang_Object_2IJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:612:
error: syntax error before "ptr_glXCreatePixmap"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:622:
error: `ptr_glXCreatePixmap' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:622:
error: `PFNGLXCREATEPIXMAPPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:622:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXCreatePixmap1__JLjava_nio_ByteBuffer_2JLjava_lang_Object_2IJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:636:
error: syntax error before "ptr_glXCreatePixmap"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:643:
error: `ptr_glXCreatePixmap' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:643:
error: `PFNGLXCREATEPIXMAPPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:643:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXCreateWindow0__JLjava_nio_ByteBuffer_2JLjava_lang_Object_2IJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:663:
error: syntax error before "ptr_glXCreateWindow"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:673:
error: `ptr_glXCreateWindow' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:673:
error: `PFNGLXCREATEWINDOWPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:673:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXCreateWindow1__JLjava_nio_ByteBuffer_2JLjava_lang_Object_2IJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:687:
error: syntax error before "ptr_glXCreateWindow"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:694:
error: `ptr_glXCreateWindow' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:694:
error: `PFNGLXCREATEWINDOWPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:694:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function `Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXDestroyPbuffer0__JJJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:752:
error: syntax error before "ptr_glXDestroyPbuffer"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:753:
error: `ptr_glXDestroyPbuffer' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:753:
error: `PFNGLXDESTROYPBUFFERPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:753:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function `Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXDestroyPixmap0__JJJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:766:
error: syntax error before "ptr_glXDestroyPixmap"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:767:
error: `ptr_glXDestroyPixmap' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:767:
error: `PFNGLXDESTROYPIXMAPPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:767:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function `Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXDestroyWindow0__JJJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:780:
error: syntax error before "ptr_glXDestroyWindow"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:781:
error: `ptr_glXDestroyWindow' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:781:
error: `PFNGLXDESTROYWINDOWPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:781:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXGetCurrentDisplay0__J':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:908:
error: syntax error before "ptr_glXGetCurrentDisplay"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:910:
error: `ptr_glXGetCurrentDisplay' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:910:
error: `PFNGLXGETCURRENTDISPLAYPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:910:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXGetCurrentReadDrawable0__J':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:937:
error: syntax error before "ptr_glXGetCurrentReadDrawable"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:939:
error: `ptr_glXGetCurrentReadDrawable' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:939:
error: `PFNGLXGETCURRENTREADDRAWABLEPROC' undeclared (first use in this
function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:939:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXGetFBConfigAttrib0__JLjava_nio_ByteBuffer_2ILjava_lang_Object_2IJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:953:
error: syntax error before "ptr_glXGetFBConfigAttrib"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:963:
error: `ptr_glXGetFBConfigAttrib' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:963:
error: `PFNGLXGETFBCONFIGATTRIBPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:963:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXGetFBConfigAttrib1__JLjava_nio_ByteBuffer_2ILjava_lang_Object_2IJ':
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:977:
error: syntax error before "ptr_glXGetFBConfigAttrib"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:984:
error: `ptr_glXGetFBConfigAttrib' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:984:
error: `PFNGLXGETFBCONFIGATTRIBPROC' undeclared (first use in this function)
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:984:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXGetFBConfigs0__JILjava_lang_Object_2IJ':

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1004:
error: syntax error before "ptr_glXGetFBConfigs"

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1014:
error: `ptr_glXGetFBConfigs' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1014:
error: `PFNGLXGETFBCONFIGSPROC' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1014:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXGetFBConfigs1__JILjava_lang_Object_2IJ':

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1035:
error: syntax error before "ptr_glXGetFBConfigs"

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1042:
error: `ptr_glXGetFBConfigs' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1042:
error: `PFNGLXGETFBCONFIGSPROC' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1042:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXGetProcAddress0__Ljava_lang_String_2J':

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1069:
error: syntax error before "ptr_glXGetProcAddress"

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1072:
error: `ptr_glXGetProcAddress' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1072:
error: `PFNGLXGETPROCADDRESSPROC' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1072:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_glXGetProcAddressARB__Ljava_lang_String_2':

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1111:
warning: assignment makes pointer from integer without a cast
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXGetSelectedEvent0__JJLjava_lang_Object_2IJ':

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1126:
error: syntax error before "ptr_glXGetSelectedEvent"

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1131:
error: `ptr_glXGetSelectedEvent' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1131:
error: `PFNGLXGETSELECTEDEVENTPROC' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1131:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXGetSelectedEvent1__JJLjava_lang_Object_2IJ':

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1144:
error: syntax error before "ptr_glXGetSelectedEvent"

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1146:
error: `ptr_glXGetSelectedEvent' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1146:
error: `PFNGLXGETSELECTEDEVENTPROC' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1146:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXGetVisualFromFBConfig0__JLjava_nio_ByteBuffer_2J':

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1165:
error: syntax error before "ptr_glXGetVisualFromFBConfig"

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1171:
error: `ptr_glXGetVisualFromFBConfig' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1171:
error: `PFNGLXGETVISUALFROMFBCONFIGPROC' undeclared (first use in this
function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1171:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXMakeContextCurrent0__JJJJJ':

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1293:
error: syntax error before "ptr_glXMakeContextCurrent"

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1295:
error: `ptr_glXMakeContextCurrent' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1295:
error: `PFNGLXMAKECONTEXTCURRENTPROC' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1295:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXQueryContext0__JJILjava_lang_Object_2IJ':

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1322:
error: syntax error before "ptr_glXQueryContext"

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1328:
error: `ptr_glXQueryContext' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1328:
error: `PFNGLXQUERYCONTEXTPROC' undeclared (first use in this function)

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1328:
error: syntax error before "intptr_t"
[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c: In
function
`Java_com_sun_opengl_impl_x11_GLX_dispatch_1glXQueryContext1__JJILjava_lang_Object_2IJ':

[cc] /usr/home/lofi/foobar/jogl/build/gensrc/native/jogl/GLX_JNI.c:1342: