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

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

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

Operating System: Linux
Platform: PC


Issuezilla Id: 357

 Description   

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

Steps to reproduce:

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

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

Exception will be thrown. Details:

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






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

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

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

Operating System: All
Platform: All


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

 Description   

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

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

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

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

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

public class HelloWorldDemo extends Frame implements GLEventListener{

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

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

{ System.exit(0); }

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

public void init(GLAutoDrawable drawable)

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

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

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

public void display(GLAutoDrawable drawable)

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

public static void main(String[] args)

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

}



 Comments   
Comment by javalution [ 01/Jun/08 ]

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

Comment by javalution [ 01/Jun/08 ]

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

Comment by javalution [ 01/Jun/08 ]

I have found a workaround that works sometimes.

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

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

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

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

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

......
if (usingVBOs)

{ gl.glBindBuffer(GL.GL_ARRAY_BUFFER, mVBO_For_ResuableTileVertices); gl.glBufferSubData(GL.GL_ARRAY_BUFFER, 0, mOutstandingGlyphsVerticesPipeline * kSizeInBytes_OneVertices_VertexData, mVertCoords); // upload only the new stuff gl.glVertexPointer(3, GL.GL_FLOAT, 0, 0); }

else

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

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

Comment by javalution [ 02/Jun/08 ]

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

Comment by javalution [ 02/Jun/08 ]

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

Comment by kbr [ 03/Jun/08 ]

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

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

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

Comment by javalution [ 03/Jun/08 ]

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

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

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

Comment by kbr [ 03/Jun/08 ]

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

Comment by javalution [ 03/Jun/08 ]

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

Comment by javalution [ 03/Jun/08 ]

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

Comment by javalution [ 19/Aug/08 ]

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

Comment by javalution [ 19/Aug/08 ]

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

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

Comment by javalution [ 19/Aug/08 ]

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

Comment by javalution [ 19/Aug/08 ]

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

Comment by javalution [ 12/Sep/08 ]

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





[JOGL-298] Flickering on Linux Created: 28/Apr/07  Updated: 28/Apr/07

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

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

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


Issuezilla Id: 298

 Description   

Apparently it isn't just on Windows that the AWT paints the background of
Canvases internally. See the above forum thread. We will need
-Dsun.awt.noerasebackground=true to be obeyed on X11 platforms and need the same
kind of per-canvas disableBackgroundErase() method implemented on the X11 side.






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

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

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

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



 Description   

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

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

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






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

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

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


 Description   

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



 Comments   
Comment by dekken [ 29/Nov/11 ]

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

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

Viola.

Comment by ranu [ 05/Dec/11 ]

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





[JOGL-214] Jogl hangs when using a JSplitPane and a GLCanvas with zero size under OSX. Created: 31/Mar/06  Updated: 31/Mar/06

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

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

Operating System: All
Platform: Macintosh


Attachments: Java Source File Main.java    
Issuezilla Id: 214

 Description   

The nightly build dated 3/23 and later hangs when using a JSplitPane and a
GLCanvas with zero size under OSX. For more info on the issue see:
http://www.javagaming.org/forums/index.php?topic=12834.0



 Comments   
Comment by tomas [ 31/Mar/06 ]

Created an attachment (id=76)
Testcase with zero size canvas





[JOGL-208] Retain persistent pointers in GLImpl Created: 06/Mar/06  Updated: 06/Mar/06

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

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

Operating System: All
Platform: All


Issuezilla Id: 208

 Description   

Persistent pointers being passed out to C by routines such as glVertexPointer
need to be retained by the GLImpl to avoid premature garbage collection. See
http://www.javagaming.org/forums/index.php?topic=12741.0 .






[JOGL-157] Add support for Java2D fonts as 3D shapes Created: 23/Apr/05  Updated: 01/Jun/05

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

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

Operating System: All
Platform: All


Attachments: Java Source File JOGLTTF.java     Zip Archive shapegeom_src.zip     Zip Archive shapegeom_src.zip    
Issuezilla Id: 157

 Description   

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

Need to integrate something like this to have portable support for 3D fonts in
JOGL. Also need a bitmap font solution.



 Comments   
Comment by kbr [ 23/Apr/05 ]

Created an attachment (id=44)
Sample code

Comment by kbr [ 27/Apr/05 ]

Created an attachment (id=45)
Revised code with bug fixes

Comment by kbr [ 16/May/05 ]

The above javagaming.org thread is titled "Shapes and Text3D" in the Xith forum
for finding it after the forum cutover.

Comment by kbr [ 01/Jun/05 ]

Created an attachment (id=55)
Another 3D font rasterizer by Davide Raccagni





[JOGL-132] wglUseFontBitmaps & wglUseFontOutlines for JOGL Created: 24/Jan/05  Updated: 24/Jan/05

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

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

Operating System: All
Platform: All


Attachments: Java Archive File JoglAddOn-src.jar    
Issuezilla Id: 132

 Description   

I've created a library that add these two missing WGL methods for Jogl :

  • wglUseFontBitmaps
  • wglUseFontOutlines

Are you interested to integrate it in Jogl ?

There are an exemple of the use of this library in my site (like all source
code).

Jérôme Jouvie (Jouvieje)

jouvieje@esstin.uhp-nancy.fr
http://www.esstin.uhp-nancy.fr/~jouvieje/
http://topresult.tomato.co.uk/~jerome/



 Comments   
Comment by jouvieje [ 24/Jan/05 ]

Created an attachment (id=28)
Contains all java and JNI (C++) sources and binaries





[JOGL-81] Incorporate Mojang's ScoreCapabilitiesChooser Created: 04/May/04  Updated: 14/Jan/05

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

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

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


Attachments: Java Source File ScoreCapabilitiesChooser.java    
Issuezilla Id: 81

 Description   

The DefaultGLCapabilitiesChooser's algorithm does a poor enough job that we
should consider replacing it. Mojang's ScoreCapabilitiesChooser seems to be a
better choice.

http://www.mojang.com/ScoreCapabilitiesChooser.java

Separately, need to figure out why the results of the underlying window system's
pixel format selection (ChoosePixelFormat or wglChoosePixelFormatARB; not sure
which one is failing) is now so bad.



 Comments   
Comment by kbr [ 14/Jan/05 ]

Created an attachment (id=26)
Mojang's ScoreCapabilitiesChooser





[JOGL-53] PBuffer render to texture support under X11 Created: 24/Nov/03  Updated: 28/Jan/05

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

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

Operating System: Linux
Platform: PC
URL: http://tkdhurepoix.chez.tiscali.fr/patch_pbuffer.tar.gz


Attachments: GZip Archive patch_pbuffer.tar.gz    
Issuezilla Id: 53

 Description   

PBuffer render to texture support under Linux / X11. The support isn't complete
yet due to an apparent malfunction of the GLX_ATI_render_texture extension, but
is usable however. There is a pixel copy during the swapBuffers(), copy that
will be removed in a (near ?) future.



 Comments   
Comment by kbr [ 28/Jan/05 ]

Created an attachment (id=31)
Copy of patch at above URL

Comment by kbr [ 28/Jan/05 ]

Changing type from RFE to Patch





[JOGL-46] Compiling JOGL under IBM JDK on x86 or ppc Created: 25/Oct/03  Updated: 25/Oct/03

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

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

Operating System: Linux
Platform: PC


Issuezilla Id: 46

 Description   

Changes necessary to compile JOGL with IBM JDK 1.4.1:

  • modified net.java.games.gluegen.StructLayout to include OS: linux CPU: x86
    (CPU: ppc or PPC for Linux/PPC, I'll look on monday, I'm pretty sure it's ppc
  • modified "java.includes.dir.linux" to not end in /linux/
    (only $JAVA_HOME/include, not $JAVA_HOME/include/linux)
  • modified "java.lib.dir.linux" to be "$ {java.home.dir}

    /jre/bin"
    (shared libraries are kept in bin in IBM's JDK)
    I don't know best how to integrate these build changes, but these are the
    changes I need to make.






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

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 378

 Description   

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

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

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

{ ... }

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

TextureIO.newTextureData(myFile, false, null);

will throw this exception:

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






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

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

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

Operating System: All
Platform: All


Issuezilla Id: 374

 Description   

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



 Comments   
Comment by kbr [ 13/May/09 ]

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

Comment by kitfox [ 14/May/09 ]

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





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

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

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

Operating System: Mac OS X
Platform: Macintosh


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

 Description   

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

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

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



 Comments   
Comment by bsder [ 14/Jun/09 ]

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

Comment by bsder [ 14/Jun/09 ]

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





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

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

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

Operating System: Linux
Platform: Other


Issuezilla Id: 376

 Description   

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

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

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

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

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

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

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

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

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



 Comments   
Comment by merscwog [ 12/Jul/09 ]

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

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

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

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

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

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

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

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

Comment by merscwog [ 13/Jul/09 ]

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

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

OpenGL Warning: XGetVisualInfo returned 0 visuals for 40c35090

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

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

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

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

Comment by sgoethel [ 16/Jul/09 ]

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

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

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

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

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

Cheers, Sven

Comment by merscwog [ 16/Jul/09 ]

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

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

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

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

Comment by sgoethel [ 19/Jul/09 ]

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

Comment by merscwog [ 20/Jul/09 ]

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





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

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

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

Operating System: All
Platform: All


Issuezilla Id: 372

 Description   

According to the OpenGL docs, the method

glDrawElementsInstancedEXT

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






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

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

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

Operating System: All
Platform: All


Issuezilla Id: 373

 Description   

The methods

CgGL.cgSetCompilerIncludeCallback
CgGL.cgSetCompilerIncludeString

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

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



 Comments   
Comment by kbr [ 01/May/09 ]

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





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

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

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

Operating System: Windows XP
Platform: All


Issuezilla Id: 369

 Description   

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

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

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

greetings
Jan






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

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

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

Operating System: Windows XP
Platform: Other


Issuezilla Id: 371

 Description   

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

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

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



 Comments   
Comment by kbr [ 03/Apr/09 ]

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





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

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

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

Operating System: Linux
Platform: Other


Issuezilla Id: 370

 Description   

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

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

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

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






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

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

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

Operating System: Windows XP
Platform: PC


Issuezilla Id: 367

 Description   

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

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



 Comments   
Comment by gibe [ 28/Jan/09 ]

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

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

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

catch (GLException e)

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

if (needFlip)

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

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

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





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

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

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

Operating System: Windows XP
Platform: PC


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

 Description   

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



 Comments   
Comment by brainbr [ 09/Dec/08 ]

Created an attachment (id=134)
Test case

Comment by brainbr [ 09/Dec/08 ]

Created an attachment (id=135)
Test image

Comment by brainbr [ 13/Apr/09 ]

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





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

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 364

 Description   

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



 Comments   
Comment by qwerty999 [ 26/Sep/08 ]

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

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

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

Comment by kbr [ 26/Sep/08 ]

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

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

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

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

Comment by qwerty999 [ 30/Sep/08 ]

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

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

-sj





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

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 362

 Description   

Hello everybody!

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

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

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

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

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

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

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

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

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

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

I did some patch job to fix this.

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

/* Change

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

    else

    { curSize /= 4; }

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

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

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

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

best regards,
Dahie






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

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

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

Operating System: All
Platform: PC


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

 Description   

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



 Comments   
Comment by caniszczyk [ 09/Jan/09 ]

Created an attachment (id=136)
JOGL License Patch





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

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

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

Operating System: All
Platform: All


Issuezilla Id: 361

 Description   

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

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

This should be added in the TextRenderer Java doc.

Jean-Baptiste






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

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

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

Operating System: All
Platform: All


Issuezilla Id: 359

 Description   

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

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

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

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

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

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



 Comments   
Comment by kbr [ 11/Jul/08 ]

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

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

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

Comment by djclayworth [ 03/Mar/09 ]

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

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

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

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

ACTUAL: Null pointer thrown.





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

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 360

 Description   

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



 Comments   
Comment by kbr [ 17/Aug/08 ]

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





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

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

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

Operating System: All
Platform: All


Issuezilla Id: 358

 Description   

Hello,

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

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

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

Thanks and Regards






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

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 353

 Description   

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

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






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

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

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

Operating System: All
Platform: All


Issuezilla Id: 355

 Description   

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

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

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

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

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






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

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

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

Operating System: All
Platform: All


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

 Description   

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



 Comments   
Comment by colinwalters [ 29/Mar/08 ]

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

Comment by kbr [ 16/Apr/08 ]

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





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

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

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

Operating System: Linux
Platform: PC


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

 Description   

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

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



 Comments   
Comment by yug [ 30/Mar/08 ]

Created an attachment (id=123)
Test class

Comment by yug [ 30/Mar/08 ]

Created an attachment (id=124)
screenshot

Comment by kbr [ 30/Mar/08 ]

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

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

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

Comment by yug [ 30/Mar/08 ]

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

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

Comment by yug [ 31/Mar/08 ]

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

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

Comment by yug [ 31/Mar/08 ]

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

Comment by kbr [ 12/Apr/08 ]

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

Comment by yug [ 13/Apr/08 ]

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

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

Comment by yug [ 13/Apr/08 ]

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

Comment by kbr [ 13/Apr/08 ]

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





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

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

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

Operating System: Windows XP
Platform: PC


Issuezilla Id: 349

 Description   

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

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

gl.glEnable(GL.GL_MULTISAMPLE);

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






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

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

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

Operating System: All
Platform: All


Issuezilla Id: 348

 Description   

The TextRenderer lacks a setFont option.

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

Jean-Baptiste






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

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

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

Operating System: Windows XP
Platform: PC


Issuezilla Id: 346

 Description   

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

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

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

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

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






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

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

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

Operating System: Mac OS X
Platform: Macintosh


Issuezilla Id: 345

 Description   

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

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

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

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

For more details, see this discussion thread:

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






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

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

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

Operating System: All
Platform: All


Issuezilla Id: 335

 Description   

gluErrorString throws ArrayIndexOutOfBoundsException with error GLU_TESS_ERROR5
(value 100155).

Jean-Baptiste






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

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

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

Operating System: All
Platform: PC


Issuezilla Id: 331

 Description   

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



 Comments   
Comment by kbr [ 08/Nov/07 ]

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

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

This gives very acceptable results for word by word processing.

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





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

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

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

Operating System: All
Platform: All


Issuezilla Id: 333

 Description   

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

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

{jogl,jogl_awt,jogl_cg}

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

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






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

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

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

Operating System: All
Platform: PC


Issuezilla Id: 330

 Description   

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

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

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

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






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

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

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

Operating System: All
Platform: PC


Issuezilla Id: 327

 Description   

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

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






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

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

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

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


Issuezilla Id: 325

 Description   

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

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

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

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

A bug should probably be filed with Apple.






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

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

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

Operating System: All
Platform: All


Issuezilla Id: 321

 Description   

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



 Comments   
Comment by kbr [ 09/Oct/07 ]

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

Comment by mbien [ 10/Oct/07 ]

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

Comment by kbr [ 10/Oct/07 ]

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

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





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

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

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

Operating System: All
Platform: All


Issuezilla Id: 320

 Description   

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



 Comments   
Comment by kbr [ 09/Oct/07 ]

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





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

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

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

Operating System: All
Platform: All


Issuezilla Id: 319

 Description   

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



 Comments   
Comment by mbien [ 09/Oct/07 ]

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

Comment by kbr [ 09/Oct/07 ]

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





[JOGL-315] Memory Leak with Overlay Created: 03/Sep/07  Updated: 18/Sep/07

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

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

Operating System: All
Platform: All


Issuezilla Id: 315

 Description   

When using an Overlay object to create a graphics context to paint with Java2D,
calling dispose on the graphics context is not enough - the underlying
TextureRenderer dispose method should also be invoked. However, the Overlay
class does not expose a mechanism to invoke the TextureRenderer dispose. The
result is a rapid consumption of memory.
The following snippet shows the basic GLEventListener I used to render the
overlay in a loop cycle - no actual painting is necessary to consume memory.

public CustomGLEventListener implements GLEventListener {

public void display(GLAutoDrawable drawable) {
Overlay overlay = new Overlay(drawable);
Graphics2D g = overlay.createGraphics();
// paint(g); // painting goes here
g.dispose();

overlay.drawAll();
//overlay.dispose(); // Recommended addition
}

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

{ /* NOOP */ }
public void init(GLAutoDrawable drawable) { /* NOOP */ }

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

{ /* NOOP */ }

}

Adding the following method to the com.sun.opengl.util.j2d.Overlay class and
invoking it when the overlay is no longer needed appears to resolve the memory
consumption problem:
public void dispose() {
renderer.dispose();
}

I expect subsequent calls to the overlay object after dispose is invoked will
throw a NullPointerException (such as if createGraphics were to be called).



 Comments   
Comment by kbr [ 17/Sep/07 ]

This isn't the recommended usage style for the Overlay. You're supposed to
create it once in your init() method and use it many times in your display
callback. See demos.j2d.TestOverlay in the jogl-demos workspace.

I agree that for completeness a dispose() call should probably be added, but
this is really more a bug in the application and not in JOGL.

Comment by jlhider [ 18/Sep/07 ]

Understood. The example was simply to demonstrate the condition where if you
stop using an overlay (and discard it), there is a risk of creeping memory
consumption. It would not likely be noticed during quick development test runs
or for short running apps, but could reveal itself in long runs of dynamic apps
(or in a brutal case such as the example). If during some point in the
application I want to use one or more overlays (for whatever reason), I should
be able to release them during the spans of time that they are not needed.

That's all.
Thanks





[JOGL-310] Enhance TextureWriter to support decompression Created: 15/Jul/07  Updated: 15/Jul/07

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

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

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


Issuezilla Id: 310

 Description   

The TextureWriter SPI interface needs to be expanded in order to support
decompression of texture data. The interface needs to look something like

boolean matches(File file);
boolean readBackCompressed();
void write(File file, TextureData data) throws IOException;






[JOGL-309] Clarify GLPbuffer setSize() documentation and exception Created: 08/Jul/07  Updated: 08/Jul/07

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

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

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


Issuezilla Id: 309

 Description   

See above forum posting for suggestion on documentation and run-time exception
clarification.






[JOGL-308] Assymetry in null GLCapabilities parameter for off-screen context creation Created: 05/Jul/07  Updated: 05/Jul/07

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

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

Operating System: All
Platform: All


Issuezilla Id: 308

 Description   

Passing a null for the GLCapabilities when creating a pbuffer throws a
NullPointerException. This is not the same for the onscreen drawables. After
looking at the source code, it appears that this is only a problem for Mac and
Windows, the X11 version checks for null.

Here's the stack trace

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at com.sun.opengl.impl.windows.WindowsGLDrawable.<init>(WindowsGLDrawabl
e.java:58)
at com.sun.opengl.impl.windows.WindowsPbufferGLDrawable.<init>(WindowsPb
ufferGLDrawable.java:62)
at com.sun.opengl.impl.windows.WindowsGLDrawableFactory$2.run(WindowsGLD
rawableFactory.java:147)
at com.sun.opengl.impl.windows.WindowsGLDrawableFactory.maybeDoSingleThr
eadedWorkaround(WindowsGLDrawableFactory.java:219)
at com.sun.opengl.impl.windows.WindowsGLDrawableFactory.createGLPbuffer(
WindowsGLDrawableFactory.java:164)
at SharedPBuffer.init(SharedPBuffer.java:87)
at com.sun.opengl.impl.GLDrawableHelper.init(GLDrawableHelper.java:72)
at javax.media.opengl.GLCanvas$InitAction.run(GLCanvas.java:307)
at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:1
89)
at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.
java:301)
at javax.media.opengl.GLCanvas.display(GLCanvas.java:133)
at javax.media.opengl.GLCanvas.paint(GLCanvas.java:166)
at sun.awt.RepaintArea.paintComponent(RepaintArea.java:248)
at sun.awt.RepaintArea.paint(RepaintArea.java:224)
at sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.java:293)
at java.awt.Component.dispatchEventImpl(Component.java:4483)
at java.awt.Component.dispatchEvent(Component.java:4237)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:600)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThre
ad.java:273)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.
java:183)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThre
ad.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)

at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
pBuffer = GLDrawableFactory.getFactory().createGLPbuffer(
null, null, 400, 400, canvas.getContext());

WindowsGLDrawable.java:58
this.capabilities = (GLCapabilities) capabilities.clone();

MacOSXGLDrawable.java:86
this.capabilities = (GLCapabilities) capabilities.clone();

  • whereas -
    X11GLDrawable.java:57
    this.capabilities = (capabilities == null) ? null :
    ((GLCapabilities) capabilities.clone());





[JOGL-305] GLJPanel does not respect border insets. Created: 27/Jun/07  Updated: 27/Jun/07

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

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

Operating System: All
Platform: All


Attachments: PNG File GLJPanel.error.png    
Issuezilla Id: 305

 Description   

The GLJPanel does not take into account the insets allocated to painting borders.



 Comments   
Comment by mvsoder [ 27/Jun/07 ]

Created an attachment (id=103)
GLJPanel Border Problem





[JOGL-303] Add GL_BGRA code path to Screenshot Created: 29/May/07  Updated: 29/May/07

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

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

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


Issuezilla Id: 303

 Description   

It would be better to use a GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV pixel format
and type in conjunction with a TYPE_INT_ARGB BufferedImage in the Screenshot
class if OpenGL 1.2 is available. This is a more optimized code path through
most vendors' OpenGL drivers. See the above forum posting.






[JOGL-302] Black line on texture created with glu Created: 23/May/07  Updated: 23/May/07

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

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

Operating System: All
Platform: All


Attachments: Java Source File gluBuild2DMipmapsTEST.java     File PLATEOX2.bmp    
Issuezilla Id: 302

 Description   

A black line appear in top of the texture created with gluBuild2DMipmaps &
jogl.glu.nojava=false

This does not occures if the texture was created with :

  • gluBuild2DMipmaps & jogl.glu.nojava=true
  • glTexImage2D

This issue does not occure with all textures, a test case and its picture can be
found here :
http://jerome.jouvie.free.fr/downloads/gluBuild2DMipmapsTEST.java
http://jerome.jouvie.free.fr/downloads/PLATEOX2.bmp



 Comments   
Comment by jouvieje [ 23/May/07 ]

Created an attachment (id=101)
Test case

Comment by jouvieje [ 23/May/07 ]

Created an attachment (id=102)
Test case image





[JOGL-301] Add support for overlay planes Created: 14/May/07  Updated: 14/May/07

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

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

Operating System: All
Platform: All


Issuezilla Id: 301

 Description   

Please add support for overlay planes. Overlay plane hardware is often found on
higher end video hardware such as nVidia's Quadro series of video cards.
Their availability can be queried through glXGetVisualConfigs and/or
glXGetFBConfigs request on X11 platforms and through the wglDescribeLayerPlane
API on Windows. I'm not sure about OSX.

Unfortunately this will require the addition of 8 bit rendering in jogl since
overlay planes are almost exclusively 8 bits deep.






[JOGL-300] Improvements to JOGL build process. Unbundling gluegen, etc Created: 08/May/07  Updated: 08/May/07

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

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

Operating System: All
Platform: All


Attachments: Text File fix-solaris-compiler.patch     Text File uncouple-gluegen.patch    
Issuezilla Id: 300

 Description   

Currently the JOGL build process depends on the gluegen directory being available.

As part of the packaging of JOGL and JOAL for gentoo. I have started to separate
gluegen from the 2 packages build environment.

Basically the main patch just adds conditional checks so that if the properties
gluegen.jar and gluegen-rt.jar are avaliable files the gluegen build process is
skipped. Hopefully this will allow a compromise between your needs and those of
opensource projects wishing to package JOGL.

Secondly I noticed that you depend on an old version of cputasks. Newer
versions do not seem to support the suncc compiler and this patch just changes
those values to gcc. this patch might not be suitable for you.



 Comments   
Comment by alistair64 [ 08/May/07 ]

Created an attachment (id=99)
Main patch to uncouple gluegen from main build

Comment by alistair64 [ 08/May/07 ]

Created an attachment (id=100)
minor patch to fix building with newer versions of cputasks

Comment by alistair64 [ 08/May/07 ]

Also of note. While the main patch stops gluegen from being built when the jars
are already available. Files located within the gluegen directory are still
required. I propose that these should be duplicated within each make directory.

Also a requirement of separation will be gluegen having separate releases.





[JOGL-286] Ask site owners to revise documentation Created: 13/Mar/07  Updated: 13/Mar/07

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

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

Operating System: All
Platform: All


Issuezilla Id: 286

 Description   

http://www.javagaming.org/forums/index.php?topic=16220.0 indicates several web
sites which refer to the pre-JSR-231 JOGL API and which would be beneficial if
they were updated. Should contact the site owners and suggest revisions to the
text and examples.






[JOGL-285] TextureIO's TGA and SGI RGB code paths should premultiply alpha Created: 27/Feb/07  Updated: 27/Feb/07

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

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

Operating System: All
Platform: Sun


Issuezilla Id: 285

 Description   

After discussion with Chris Campbell from the Java 2D team, it is clear that the
TGA and SGI RGB incoming code paths to the TextureIO classes should premultiply
the alpha channel in to the image data if it is present, to obey the general
contract that TextureIO always premultiplies image data. The ImageIO code paths
have been changed to obey this same contract.






[JOGL-283] GLBufferStateTracker produces too much garbage Created: 27/Feb/07  Updated: 27/Feb/07

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

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

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


Issuezilla Id: 283

 Description   

The thread http://www.javagaming.org/forums/index.php?topic=15989.0 indicates
that the GLBufferStateTracker, needed for catching misuse of the VBO/PBO-related
entry points, is producing too much garbage.






[JOGL-268] Add API for querying graphics card and driver information Created: 07/Feb/07  Updated: 07/Feb/07

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

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

Operating System: All
Platform: Sun


Issuezilla Id: 268

 Description   

The LWJGL project has APIs to query various graphics card and driver
information. This has been noted by customers as being potentially useful both
for troubleshooting and potentially implementing workarounds for older cards, so
similar APIs should be added to JOGL.






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

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

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

Operating System: All
Platform: All


Issuezilla Id: 254

 Description   

This would make GUI layout simpler and encourage JOGL adoption.



 Comments   
Comment by kbr [ 01/Dec/06 ]

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

Comment by ophir [ 01/Dec/06 ]

Sure, it's discussed on this thread:

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

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

Comment by kbr [ 02/Dec/06 ]

Please do try it again and report the results.

Comment by wyadams [ 30/Sep/11 ]

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





[JOGL-252] Add TextureIO Section to User's Guide Created: 27/Nov/06  Updated: 27/Nov/06

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

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

Operating System: All
Platform: All


Issuezilla Id: 252

 Description   

The TextureIO classes should be documented in the JOGL User's Guide.






[JOGL-251] ptrdiff_t conversion is wrong in JOGL Created: 23/Nov/06  Updated: 23/Nov/06

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

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

Operating System: All
Platform: All


Issuezilla Id: 251

 Description   

The C-level "ptrdiff_t" data type is being mapped to the Java type "int" by
GlueGen, which is incorrect. It should be mapped to type "long" for 64-bit
safety. It is not completely clear why this is happening. Updating
make/stub_includes/common/stddef.h with the correct typedef does not fix the
problem. More investigation is needed. Once this is correctly changed, we need
to provide manual trampoline methods with the original signatures taking "int"
in order to maintain backward binary compatibility.






[JOGL-223] Swing components only update GL_LEFT buffer in stereo mode Created: 18/May/06  Updated: 19/May/06

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

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

Operating System: Windows XP
Platform: All


Issuezilla Id: 223

 Description   

When I create a GLCanvas with a GLCapabilties with setStereo(true), Swing
controls don't seem to all work properly. Some of them (e.g. buttons) work
fine, but others only change the output to the left buffer of the graphics card.
For example, a JTextBox, when generated, shows the default text in both the
GL_LEFT and the GL_RIGHT buffer, but if the text is changed, only the GL_LEFT
buffer is updated.This problem also "spreads" to other Swing components if the
GLCanvas is dragged around the screen to conver and later uncovers them - after
this, only the GL_LEFT buffer is updated.



 Comments   
Comment by kbr [ 19/May/06 ]

It is highly unlikely that anything can be done about this. The underlying
Java2D pipeline which renders the Swing controls knows nothing about OpenGL
stereo modes which is why the components are only appearing in one of the two
buffers. Even with the new fully-accelerated GLJPanel available with Java SE 6,
the underlying Java2D window is not stereo capable. We might be able to address
the latter with an RFE in the JDK.

I hope a quick resolution of this issue is not necessary. If one is then I would
strongly encourage you to look for workarounds involving drawing minimal
components using pure OpenGL.





[JOGL-222] Stereo Mode on a GLJPanel Created: 08/May/06  Updated: 08/May/06

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

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

Operating System: Windows XP
Platform: All


Issuezilla Id: 222

 Description   

Stereo mode does not seem to work on a GLJPanel. I set up a simple testing
program with a GLCanvas that works perfectly displaying stereo images, but if I
switch it over to GLJPanel, the program only draws to the GL_LEFT buffer and
throws an exception indicating that the buffer doesn't exist if I pipeline in a
DebugGL and call glDrawBuffer(GL_RIGHT).



 Comments   
Comment by kbr [ 08/May/06 ]

This isn't surprising to me as the rendering path for the GLJPanel is
drastically different than that for the GLCanvas. In particular the rendering
all goes off-screen to a pbuffer and from there is read back and blitted to the
screen using Java2D, so there is no way the OpenGL driver can get involved in
the display of stereo. Even when the Java2D/JOGL bridge is active (with Mustang
builds and -Dsun.java2d.opengl=true), we don't get a chance to choose the pixel
format for the underlying surface so there's basically no way stereo can work. I
think for now you'll have to use a heavyweight GLCanvas to do stereo.





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

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

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

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



 Description   

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



 Comments   
Comment by eban [ 25/Feb/14 ]

Sorry, wrong bugtracker, please disregard/delete this ticket





[JOGL-163] Extend Render-to-Texture functionality to include Render-to-Depth-Texture Created: 05/Jun/05  Updated: 07/Feb/06

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

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

Operating System: All
Platform: All
URL: http://www.cs.rutgers.edu/~tedmunds/jogl/renderToDepthTexture.zip


Attachments: Java Source File RenderToTextureFBO.java    
Issuezilla Id: 163

 Description   

The current render-to-texture functionality makes use of the
WGL_ARB_render_texture extension to allow a Pbuffer's colour buffer to be bound
to a texture. It would also be useful to be able to use the
WGL_NV_render_depth_texture extension to allow binding of the Pbuffer's depth
buffer to a depth texture. The implementation of such a feature (on Windows)
could parallel the already present render-to-texture functionality. An example
of such an implementation is available at
http://www.cs.rutgers.edu/~tedmunds/jogl/renderToDepthTexture.zip.

The implementation makes the following modifications to the JOGL code base:
net.java.games.jogl.GLCapabilities:

  • Add a boolean field offscreenRenderToDepthTexture (similar to
    offscreenRenderToTexture) that indicates whether the created Pbuffer should
    allow render-to-depth-texture.
  • Add accessors (getOffscreenRenderToDepthTexture(),
    setOffscreenRenderToDepthTexture(boolean onOrOff) for the above field.
    net.java.games.jogl.GLPbuffer:
  • Add a method bindDepthTexture() (similar to bindTexture()) that calls for
    the Pbuffer's depth buffer to be bound to GL_TEXTURE_2D or
    GL_TEXTURE_RECTANGLE_NV.
  • Add a method releaseDepthTexture() that parallel's depthTexture().
    net.java.games.jogl.impl.GLPbufferImpl:
  • Implement the added GLPbuffer interface methods (above) by calling the
    corresponding methods on the context (below)
    net.java.games.jogl.impl.GLContext:
  • Add an abstract method bindPbufferToDepthTexture() (similar to
    bindPbufferToTexture()).
  • Add an abstract method releasePbufferFromDepthTexture() (similar to
    releasePbufferFromTexture()).
    net.java.games.jogl.impl.windows.OffscreenGLContext/OnscreenGLContext:
  • Implement the added GLContext abstract methods (above) with versions that
    throw exceptions indicating that they should not be called.
    net.java.games.jogl.impl.windows.WindowsPbufferGLContext:
  • Add a field rtdt (similar to rtt) indicating whether render-to-depth-texture
    is enabled.
  • Add a field hasRTDT (similar to RTDT) indicating whether the
    render-to-depth-texture extension is available.
  • Add a field depthTexture (similar to texture) that holds the texture object
    ID of the depth texture.
  • Modify the constructor's DEBUG output to include rtdt.
  • Implement bindPbufferToDepthTexture() in a manner similar to
    bindPbufferToTexture(), except that the wglBindTexImageARB() call binds to
    WGL_DEPTH_COMPONENT_NV instead of WGL_FRONT_LEFT_ARB.
  • Implement releasePbufferFromDepthTexture() (with the same relationship to
    releasePbufferFromTexture()).
  • Modify createPbuffer(long, long):
  • Initialize rtdt from the capabilities.
  • On many of the tests that check whether rtt == true, modify to check
    whether (rtt || rtdt) == true.
  • If rtdt, add to the iattributes array the pair:
    WGL_BIND_TO_TEXTURE_RECTANGLE_DEPTH_NV or
    WGL_BIND_TO_TEXTURE_DEPTH_NV (depending on rect) and GL_TRUE (to enable
    binding of the depth buffer to a texture).
  • In the NVidia work-around loop, if rtdt, add the
    WGL_DEPTH_TEXTURE_FORMAT_NV and WGL_TEXTURE_DEPTH_COMPONENT_NV pair to the
    iattributes array.
  • Modify makeCurrent(Runnable):
  • Initialize rtdt from the capabilities.
  • Determine the render-to-texture-rectangle settings if rtt or rtdt is true.
  • If rtdt:
  • Determine whether the render-to-depth-texture extension is available.
  • Generate a texture to be bound to the depth buffer.
  • Bind the generated texture to the texture target.
  • Configure the texture lookup parameters.
  • Choose the internal format of the texture (one of the depth formats)
  • Create the texture with null contents.
  • Modify swapBuffers():
  • If render-to-depth-texture is enabled (rtdt), but the extension is not
    available (!hasRTDT), copy the depth buffer to the depth texture.
  • In both the new copying case and the existing colour buffer copy, bind the
    appropriate texture to the texture target before copying.
    net.java.games.jogl.impl.macosx.MacOSX*GLContext:
    net.java.games.jogl.impl.x11.X11*GLContext:
  • Not yet implemented (methods added with comments/exceptions to that effect)

Design decisions:

  • By paralleling render-to-depth-texture alongside render-to-texture, it is
    possible to bind both the colour buffer and the depth buffer of a Pbuffer to
    (different) textures.
  • For simplicity, the existing render-to-texture-rect settings are made to
    apply to both the colour and depth textures. It should be possible to allow
    (eg.) the colour buffer to be bound to GL_TEXTURE_RECTANGLE_NV, and the
    depth buffer to be bound to GL_TEXTURE_2D, but it doesn't seem that useful.

Notes:

  • The example patch was created against the latest source from CVS as of
    June 4, 2005.
  • As well as implementing the described render-to-depth-texture functionality,
    the example patch implements the exposure of the texture target (i.e.
    allowing the API programmer to determine whether the buffers are bound to
    GL_TEXTURE_2D or GL_TEXTURE_RECTANGLE_NV.
  • Also included in the source archive is and example application
    (RenderToTexture.java) that demonstrates the combined use of
    render-to-texture and render-to-depth-texture.


 Comments   
Comment by kbr [ 22/Jun/05 ]

Thanks for the suggestion and patch. However, the OpenGL community is moving
away from pbuffers and toward the frame buffer object extension, which is a more
portable and higher-performance solution for offscreen rendering than pbuffers.
I'm therefore reluctant to enhance JOGL's pbuffer implementation significantly
at this time, because we're trying to stabilize the final release of the current
JOGL APIs. Your patch will be considered for a future version of JOGL
implementing the JSR-231 APIs.

Comment by tedmunds [ 07/Feb/06 ]

Created an attachment (id=70)
Framebuffer object implementation of the desired functionality.





[JOGL-164] Expose render-to-texture target Created: 05/Jun/05  Updated: 22/Jun/05

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

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

Operating System: All
Platform: All


Issuezilla Id: 164

 Description   

The current render-to-texture functionality allows a Pbuffer to be bound to either
GL_TEXTURE_2D or GL_TEXTURE_RECTANGLE_NV (based on the value of
offscreenRenderToTextureRectangle set in the GLCapabalities object). However,
in some cases, the resulting texture target may not be what the programmer
expects (eg. if GL_TEXTURE_RECTANGLE_NV is not available). By adding an
accessor to GLPbuffer (and, hence to GLPbufferImpl as well as GLContext and all
its subclasses), the actual texture target being used could be made available to
the API programmer.

Issue 163 refers to an implementation that also includes an implementation of
this feature.



 Comments   
Comment by kbr [ 22/Jun/05 ]

Thanks for the suggestion and patch. However, the OpenGL community is moving
away from pbuffers and toward the frame buffer object extension, which is a more
portable and higher-performance solution for offscreen rendering than pbuffers.
I'm therefore reluctant to enhance JOGL's pbuffer implementation significantly
at this time, because we're trying to stabilize the final release of the current
JOGL APIs. Your patch will be considered for a future version of JOGL
implementing the JSR-231 APIs.





[JOGL-250] Fix getChosenGLCapabilities for Java2D/JOGL bridge Created: 19/Nov/06  Updated: 19/Nov/06

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

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

Operating System: All
Platform: All


Issuezilla Id: 250

 Description   

The new GLDrawable.getChosenGLCapabilities() does not provide correct answers
for the GLJPanel when the Java2D/JOGL bridge is active, and will provide a null
answer when called on an "external" GLDrawable. Should investigate whether it is
possible to provide better answers in these cases and to do so if possible.






[JOGL-243] Exception when destroying a Pbuffer while context is current Created: 14/Aug/06  Updated: 14/Aug/06

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

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

Operating System: All
Platform: All


Attachments: Text File PbufferDestroyBug.form     Java Source File PbufferDestroyBug.java    
Issuezilla Id: 243

 Description   

If a Pbuffer is destroyed while a context created on that Pbuffer is current, an
exception will result the next time any context is made current. One could argue
that this is an app bug, but I am fairly certain that native OpenGL drivers
handle this case correctly.

To reproduce, run the attached test program. When you press the "DestroyPbuffer"
button, a new context is created on the Pbuffer, the new context is made
current, then the Pbuffer is destroyed. The following exception is thrown the
next time the on-screen context is made current:

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: Pbuffer
destroyed out from under application-created context
at
com.sun.opengl.impl.x11.X11PbufferGLContext.releaseImpl(X11PbufferGLContext.java:114)
at com.sun.opengl.impl.GLContextImpl.release(GLContextImpl.java:159)
at com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:114)
at PbufferDestroyBug$MyCanvas.paint(PbufferDestroyBug.java:156)
at java.awt.Canvas.update(Canvas.java:114)
at sun.awt.RepaintArea.updateComponent(RepaintArea.java:239)
at sun.awt.X11.XRepaintArea.updateComponent(XRepaintArea.java:43)
at sun.awt.RepaintArea.paint(RepaintArea.java:216)
at sun.awt.X11.XComponentPeer.handleEvent(XComponentPeer.java:630)
at java.awt.Component.dispatchEventImpl(Component.java:4031)
at java.awt.Component.dispatchEvent(Component.java:3803)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
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)

Note that if you check the "Release pcontext" check box prior to pressing the
"Destroy Pbuffer" button, then the app will release the context prior to
destroying the pbuffer and there will be no exception.



 Comments   
Comment by kcr [ 14/Aug/06 ]

Created an attachment (id=83)
Test program

Comment by kcr [ 14/Aug/06 ]

Created an attachment (id=84)
NB5 form file





[JOGL-202] Render to texture no longer working correctly Created: 07/Feb/06  Updated: 15/Feb/06

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

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

Operating System: Windows XP
Platform: PC
URL: http://www.cs.rutgers.edu/~tedmunds/share/jogl/RenderToTextureBasic.java


Attachments: Java Source File RenderToTextureBasic.java     Java Source File RenderToTextureFBO.java    
Issuezilla Id: 202

 Description   

The (relatively) recent changes to how Pbuffer contexts are managed has resulted
in undesirable behaviour on a simple render-to-texture test case. In the test
case, the Pbuffer is bound to a texture, a scene is rendered to the Pbuffer, the
Pbuffer is unbound, and then the texture is used in rendering to the main frame
buffer. Before the implementation changes for JSR-231, this test application
functioned correctly (i.e. when the texture was mapped onto a rectangle, the
image was as expected); now, the rendering to texture does not seem to have been
completed before the texture is accessed for rendering in the frame buffer. By
alternating the colour of the scene each time when rendering to the Pbuffer, it
becomes clear that the texture access is getting a mix of the old contents and
the new contents of the Pbuffer.

This behaviour is present in both the latest release and the latest nightly build.

The associated URL points to the code for the example application.



 Comments   
Comment by tedmunds [ 07/Feb/06 ]

Created an attachment (id=69)
Example application (in demos.renderToTexture package).

Comment by tedmunds [ 07/Feb/06 ]

I have downgraded the priority of this defect after discovering that the
framebuffer object extension is now sufficiently accessible to provide the
desired functionality. An example implementation using framebuffer objects that
corresponds to the submitted defect example is available at
http://www.cs.rutgers.edu/~tedmunds/share/jogl/RenderToTextureFBO.java (and will
be attached to this issue).

Comment by tedmunds [ 07/Feb/06 ]

Created an attachment (id=71)
Framebuffer object implementation of the desired functionality

Comment by kbr [ 15/Feb/06 ]

The basic problem doesn't seem to be reproducible, at least not on all hardware.
The RenderToTextureBasic test case seems to render properly, with four orange
teapots showing up on the square background behind the gray teapot. It's
possible that an appropriately-placed glFinish() call in the application will
cause it to behave better.

In general the render-to-texture support in the GLCapabilities is non-portable
and not to be relied on. The submitter is correct that FBOs are the best way to
do render-to-texture portably.

This bug will probably be closed as "works for me", but would like to
incorporate these test cases, slightly modified, into the jogl-demos package.
Will contact the submitter for permission.





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

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

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

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


Issuezilla Id: 366

 Description   

Reported against the Debian package:

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

When I try the demos:

  • Hardware Shadow Mapping
  • JRefract

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

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



 Comments   
Comment by kbr [ 06/Jan/09 ]

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

Comment by sylvestre12 [ 07/Jan/09 ]

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

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

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

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

Comment by kbr [ 07/Jan/09 ]

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

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

The community will probably need to contribute these fixes.

Comment by sylvestre12 [ 09/Jan/09 ]

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

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

Comment by kbr [ 09/Jan/09 ]

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





[JOGL-311] Unable to make context current and crashes vm when useing release and rc3 Created: 05/Aug/07  Updated: 07/Aug/07

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

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

Operating System: All
Platform: All


Issuezilla Id: 311

 Description   

Receiving "Exception in thread "AWT-EventQueue-0"
javax.media.opengl.GLException: Error making context current" in the current
release and the release candidate when using GLJPanel. This was solved in
earlier JSR-231 releases. This seems to only happen when using a GLJPanel. I
also tried with the JOGL RC3 and it crashes the JVM. I have included the vm
error log next.
**********************************************************************************
#

  1. An unexpected error has been detected by Java Runtime Environment:
    #
  2. SIGSEGV (0xb) at pc=0xb535a317, pid=20461, tid=2954005392
    #
  3. Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode, sharing)
  4. Problematic frame:
  5. C [libX11.so.6+0x32317] XQueryExtension+0x17
    #
  6. If you would like to submit a bug report, please visit:
  7. http://java.sun.com/webapps/bugreport/crash.jsp
    #

--------------- T H R E A D ---------------

Current thread (0x0848b800): JavaThread "AWT-EventQueue-0" [_thread_in_native,
id=20481]

siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x000004d0

Registers:
EAX=0xb44f80ad, EBX=0xb5415b2c, ECX=0x084bc7a8, EDX=0x00000000
ESP=0xb0127570, EBP=0xb01275b8, ESI=0x00000000, EDI=0x00000000
EIP=0xb535a317, CR2=0x000004d0, EFLAGS=0x00010282

Top of Stack: (sp=0xb0127570)
0xb0127570: b7f20150 00001ae0 00000000 00000001
0xb0127580: b0127634 0848b800 b0127724 b01275ac
0xb0127590: 063057d8 b0127704 b01275e0 b0127634
0xb01275a0: 0848b800 00000000 00000000 b5415b2c
0xb01275b0: 00000000 00000000 b01275f8 b534ec6b
0xb01275c0: 00000000 b44f80ad b01275e0 b01275e4
0xb01275d0: b01275e8 b7f20120 0848b800 b01275f8
0xb01275e0: b7e4b60e b7f20120 00000010 b5838158

Instructions: (pc=0xb535a317)
0xb535a307: ec 3c 8b 7d 08 e8 36 51 fe ff 81 c3 1b b8 0b 00
0xb535a317: 8b 87 d0 04 00 00 85 c0 74 05 89 3c 24 ff 10 8b

Stack: [0xb00d8000,0xb0129000), sp=0xb0127570, free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libX11.so.6+0x32317] XQueryExtension+0x17
C [libX11.so.6+0x26c6b] XInitExtension+0x3b
C [libXext.so.6+0xc433] XextAddDisplay+0x53
C [libGL.so.1+0x20704]
C [libGL.so.1+0x20f64] __glXInitialize+0x14
C [libGL.so.1+0x21f6f] __glXSetupForCommand+0x3f
C [libGL.so.1+0x2020b]
C [libjogl.so+0x48bf1] Java_com_sun_opengl_impl_x11_GLX_glXDestroyContext__JJ+0x3e
j com.sun.opengl.impl.x11.GLX.glXDestroyContext(JJ)V+0
j com.sun.opengl.impl.x11.X11GLContext.destroyImpl()V+78
j com.sun.opengl.impl.GLContextImpl.destroy()V+60
j javax.media.opengl.GLJPanel.removeNotify()V+77
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j javax.swing.JRootPane.removeNotify()V+5
j java.awt.Container.removeNotify()V+38
j java.awt.Window.removeNotify()V+16
j java.awt.Frame.removeNotify()V+51
j java.awt.Window$1DisposeAction.run()V+137
j java.awt.Window.doDispose()V+16
j java.awt.Window.dispose()V+1
j org.davincisoft.DaVinci.cleanUp()V+28
j org.davincisoft.DaVinci.windowClosing(Ljava/awt/event/WindowEvent;)V+11
j java.awt.AWTEventMulticaster.windowClosing(Ljava/awt/event/WindowEvent;)V+8
j java.awt.AWTEventMulticaster.windowClosing(Ljava/awt/event/WindowEvent;)V+8
j java.awt.Window.processWindowEvent(Ljava/awt/event/WindowEvent;)V+68
j javax.swing.JFrame.processWindowEvent(Ljava/awt/event/WindowEvent;)V+2
j java.awt.Window.processEvent(Ljava/awt/AWTEvent;)V+69
j java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+562
j java.awt.Container.dispatchEventImpl(Ljava/awt/AWTEvent;)V+42
j java.awt.Window.dispatchEventImpl(Ljava/awt/AWTEvent;)V+19
j java.awt.Component.dispatchEvent(Ljava/awt/AWTEvent;)V+2
j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+46
j java.awt.EventDispatchThread.pumpOneEventForFilters(I)Z+156
j
java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+30
j
java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j java.awt.EventDispatchThread.run()V+9
v ~StubRoutines::call_stub
V [libjvm.so+0x20967d]
V [libjvm.so+0x3057d8]
V [libjvm.so+0x208f90]
V [libjvm.so+0x20901d]
V [libjvm.so+0x279215]
V [libjvm.so+0x38035f]
V [libjvm.so+0x3066b3]
C [libpthread.so.0+0x531b]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.sun.opengl.impl.x11.GLX.glXDestroyContext(JJ)V+0
j com.sun.opengl.impl.x11.X11GLContext.destroyImpl()V+78
j com.sun.opengl.impl.GLContextImpl.destroy()V+60
j javax.media.opengl.GLJPanel.removeNotify()V+77
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j java.awt.Container.removeNotify()V+38
j javax.swing.JComponent.removeNotify()V+1
j javax.swing.JRootPane.removeNotify()V+5
j java.awt.Container.removeNotify()V+38
j java.awt.Window.removeNotify()V+16
j java.awt.Frame.removeNotify()V+51
j java.awt.Window$1DisposeAction.run()V+137
j java.awt.Window.doDispose()V+16
j java.awt.Window.dispose()V+1
j org.davincisoft.DaVinci.cleanUp()V+28
j org.davincisoft.DaVinci.windowClosing(Ljava/awt/event/WindowEvent;)V+11
j java.awt.AWTEventMulticaster.windowClosing(Ljava/awt/event/WindowEvent;)V+8
j java.awt.AWTEventMulticaster.windowClosing(Ljava/awt/event/WindowEvent;)V+8
j java.awt.Window.processWindowEvent(Ljava/awt/event/WindowEvent;)V+68
j javax.swing.JFrame.processWindowEvent(Ljava/awt/event/WindowEvent;)V+2
j java.awt.Window.processEvent(Ljava/awt/AWTEvent;)V+69
j java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+562
j java.awt.Container.dispatchEventImpl(Ljava/awt/AWTEvent;)V+42
j java.awt.Window.dispatchEventImpl(Ljava/awt/AWTEvent;)V+19
j java.awt.Component.dispatchEvent(Ljava/awt/AWTEvent;)V+2
j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+46
j java.awt.EventDispatchThread.pumpOneEventForFilters(I)Z+156
j
java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+30
j
java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j java.awt.EventDispatchThread.run()V+9
v ~StubRoutines::call_stub

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
=>0x0848b800 JavaThread "AWT-EventQueue-0" [_thread_in_native, id=20481]
0x0842fc00 JavaThread "Timer-0" [_thread_blocked, id=20480]
0x08413400 JavaThread "TimerQueue" daemon [_thread_blocked, id=20479]
0x08058c00 JavaThread "DestroyJavaVM" [_thread_blocked, id=20465]
0x082a2000 JavaThread "AWT-Shutdown" [_thread_blocked, id=20475]
0x0829f400 JavaThread "AWT-XAWT" daemon [_thread_blocked, id=20474]
0x08282000 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=20473]
0x0808dc00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=20471]
0x0808c400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=20470]
0x0808b000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=20469]
0x08082000 JavaThread "Finalizer" daemon [_thread_blocked, id=20468]
0x08081000 JavaThread "Reference Handler" daemon [_thread_blocked, id=20467]

Other Threads:
0x08077800 VMThread [id=20466]
0x0808f400 WatcherThread [id=20472]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
def new generation total 960K, used 104K [0x8bff0000, 0x8c0f0000, 0x8c4d0000)
eden space 896K, 10% used [0x8bff0000, 0x8c007760, 0x8c0d0000)
from space 64K, 16% used [0x8c0e0000, 0x8c0e2970, 0x8c0f0000)
to space 64K, 0% used [0x8c0d0000, 0x8c0d0000, 0x8c0e0000)
tenured generation total 4096K, used 1396K [0x8c4d0000, 0x8c8d0000, 0x8fff0000)
the space 4096K, 34% used [0x8c4d0000, 0x8c62d2b8, 0x8c62d400, 0x8c8d0000)
compacting perm gen total 12288K, used 2620K [0x8fff0000, 0x90bf0000, 0x93ff0000)
the space 12288K, 21% used [0x8fff0000, 0x9027f338, 0x9027f400, 0x90bf0000)
ro space 8192K, 73% used [0x93ff0000, 0x945ce548, 0x945ce600, 0x947f0000)
rw space 12288K, 57% used [0x947f0000, 0x94ee16c0, 0x94ee1800, 0x953f0000)

Dynamic libraries:
06000000-06412000 r-xp 00000000 07:00 482152
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/libjvm.so
06412000-0642b000 rwxp 00411000 07:00 482152
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/libjvm.so
0642b000-0684a000 rwxp 0642b000 00:00 0
08048000-08052000 r-xp 00000000 07:00 465784
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/bin/java
08052000-08053000 rwxp 00009000 07:00 465784
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/bin/java
08053000-08766000 rwxp 08053000 00:00 0 [heap]
8bff0000-8c0f0000 rwxp 8bff0000 00:00 0
8c0f0000-8c4d0000 rwxp 8c0f0000 00:00 0
8c4d0000-8c8d0000 rwxp 8c4d0000 00:00 0
8c8d0000-8fff0000 rwxp 8c8d0000 00:00 0
8fff0000-90bf0000 rwxp 8fff0000 00:00 0
90bf0000-93ff0000 rwxp 90bf0000 00:00 0
93ff0000-945cf000 r-xs 00001000 07:00 482239
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
945cf000-947f0000 rwxp 945cf000 00:00 0
947f0000-94ee2000 rwxp 005e0000 07:00 482239
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
94ee2000-953f0000 rwxp 94ee2000 00:00 0
953f0000-954c9000 rwxp 00cd2000 07:00 482239
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
954c9000-957f0000 rwxp 954c9000 00:00 0
957f0000-957f4000 r-xs 00dab000 07:00 482239
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
957f4000-95bf0000 rwxp 957f4000 00:00 0
b00d8000-b00db000 ---p b00d8000 00:00 0
b00db000-b0129000 rwxp b00db000 00:00 0
b0129000-b2869000 rwxs ca0c0000 00:0d 17249 /dev/dri/card0
b2869000-b2ea9000 rwxs cc800000 00:0d 17249 /dev/dri/card0
b2ea9000-b34e9000 rwxs cd000000 00:0d 17249 /dev/dri/card0
b34e9000-b3b29000 rwxs 28004000 00:0d 17249 /dev/dri/card0
b3b29000-b4169000 rwxs c0020000 00:0d 17249 /dev/dri/card0
b4169000-b43a5000 r-xp 00000000 07:00 513689 /usr/lib/dri/i915_dri.so
b43a5000-b43b4000 rwxp 0023c000 07:00 513689 /usr/lib/dri/i915_dri.so
b43b4000-b43bf000 rwxp b43b4000 00:00 0
b43bf000-b449a000 r-xp 00000000 07:01 61251
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/libjogl.so
b449a000-b449b000 rwxp 000da000 07:01 61251
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/libjogl.so
b449b000-b44a3000 r-xp 00000000 07:00 234011 /usr/lib/libdrm.so.2.3.0
b44a3000-b44a4000 rwxp 00008000 07:00 234011 /usr/lib/libdrm.so.2.3.0
b44a4000-b44a8000 r-xp 00000000 07:00 234058 /usr/lib/libXxf86vm.so.1.0.0
b44a8000-b44a9000 rwxp 00003000 07:00 234058 /usr/lib/libXxf86vm.so.1.0.0
b44a9000-b4506000 r-xp 00000000 07:00 234110 /usr/lib/libGL.so.1.2
b4506000-b4508000 rwxp 0005d000 07:00 234110 /usr/lib/libGL.so.1.2
b4508000-b4509000 rwxp b4508000 00:00 0
b450e000-b4510000 rwxs e083b000 00:0d 17249 /dev/dri/card0
b4510000-b4511000 r-xp 00000000 07:01 61252
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/libjogl_awt.so
b4511000-b4512000 rwxp 00001000 07:01 61252
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/libjogl_awt.so
b4512000-b4513000 r-xp 00000000 07:00 482184
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjawt.so
b4513000-b4514000 rwxp 00000000 07:00 482184
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjawt.so
b4514000-b4515000 r-xp 00000000 07:01 61250
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/libgluegen-rt.so
b4515000-b4516000 rwxp 00000000 07:01 61250
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/libgluegen-rt.so
b4516000-b4576000 rwxs 00000000 00:08 21168158 /SYSV00000000 (deleted)
b4576000-b47f3000 rwxs 00000000 00:08 21135388 /SYSV00000000 (deleted)
b47f3000-b47f6000 ---p b47f3000 00:00 0
b47f6000-b4844000 rwxp b47f6000 00:00 0
b4844000-b4847000 ---p b4844000 00:00 0
b4847000-b4895000 rwxp b4847000 00:00 0
b4895000-b4897000 r-xp 00000000 07:00 282450
/usr/lib/pango/1.6.0/modules/pango-basic-fc.so
b4897000-b4898000 rwxp 00001000 07:00 282450
/usr/lib/pango/1.6.0/modules/pango-basic-fc.so
b4898000-b4915000 r-xp 00000000 07:00 264367
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf
b4915000-b491c000 r-xp 00000000 07:00 482166
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnio.so
b491c000-b491d000 rwxp 00006000 07:00 482166
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnio.so
b491d000-b4930000 r-xp 00000000 07:00 482165
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnet.so
b4930000-b4931000 rwxp 00013000 07:00 482165
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnet.so
b4931000-b4937000 r-xs 00000000 07:00 542061
/var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-x86.cache-2
b4937000-b4938000 r-xs 00000000 07:00 543336
/var/cache/fontconfig/fd9505950c048a77dc4b710eb6a628ed-x86.cache-2
b4938000-b493b000 r-xs 00000000 07:00 543335
/var/cache/fontconfig/ddc79d3ea06a7c6ffa86ede85f3bb5df-x86.cache-2
b493b000-b493c000 r-xs 00000000 07:00 543334
/var/cache/fontconfig/e7071f4a29fa870f4323321c154eba04-x86.cache-2
b493c000-b493d000 r-xs 00000000 07:00 543333
/var/cache/fontconfig/a2ab74764b07279e7c36ddb1d302cf26-x86.cache-2
b493d000-b4941000 r-xs 00000000 07:00 542055
/var/cache/fontconfig/921a30a17f0be15c70ac14043cb7a739-x86.cache-2
b4941000-b4942000 r-xs 00000000 07:00 543331
/var/cache/fontconfig/4c73fe0c47614734b17d736dbde7580a-x86.cache-2
b4942000-b4944000 r-xs 00000000 07:00 543330
/var/cache/fontconfig/646addb8444faa74ee138aa00ab0b6a0-x86.cache-2
b4944000-b4946000 r-xs 00000000 07:00 543329
/var/cache/fontconfig/20bd79ad97094406f7d1b9654bfbd926-x86.cache-2
b4946000-b4947000 r-xs 00000000 07:00 543328
/var/cache/fontconfig/75a2cd575a62c63e802c11411fb87c37-x86.cache-2
b4947000-b4949000 r-xs 00000000 07:00 543327
/var/cache/fontconfig/9c0624108b9a2ae8552f664125be8356-x86.cache-2
b4949000-b494f000 r-xs 00000000 07:00 543326
/var/cache/fontconfig/6d41288fd70b0be22e8c3a91e032eec0-x86.cache-2
b494f000-b4951000 r-xs 00000000 07:00 543325
/var/cache/fontconfig/de156ccd2eddbdc19d37a45b8b2aac9c-x86.cache-2
b4951000-b4953000 r-xs 00000000 07:00 542898
/var/cache/fontconfig/da1bd5ca8443ffe22927a23ce431d198-x86.cache-2
b4953000-b495b000 r-xs 00000000 07:00 542897
/var/cache/fontconfig/e3de0de479f42330eadf588a55fb5bf4-x86.cache-2
b495b000-b4961000 r-xs 00000000 07:00 542834
/var/cache/fontconfig/0f34bcd4b6ee430af32735b75db7f02b-x86.cache-2
b4961000-b4962000 r-xs 00000000 07:00 542833
/var/cache/fontconfig/4794a0821666d79190d59a36cb4f44b5-x86.cache-2
b4962000-b4964000 r-xs 00000000 07:00 542832
/var/cache/fontconfig/de9486f0b47a4d768a594cb4198cb1c6-x86.cache-2
b4964000-b496a000 r-xs 00000000 07:00 542831
/var/cache/fontconfig/d52a8644073d54c13679302ca1180695-x86.cache-2
b496a000-b496d000 r-xs 00000000 07:00 542830
/var/cache/fontconfig/6386b86020ecc1ef9690bb720a13964f-x86.cache-2
b496d000-b4971000 r-xs 00000000 07:00 542039
/var/cache/fontconfig/089dead882dea3570ffc31a9898cfb69-x86.cache-2
b4971000-b4973000 r-xs 00000000 07:00 542033
/var/cache/fontconfig/e13b20fdb08344e0e664864cc2ede53d-x86.cache-2
b4973000-b4974000 r-xs 00000000 07:00 543362
/var/cache/fontconfig/fcff1cd55d48a2c86a175e9943c3506d-x86.cache-2
b4974000-b4975000 r-xs 00000000 07:00 543361
/var/cache/fontconfig/e9e44584608a73233979f764b5f9dd81-x86.cache-2
b4975000-b4976000 r-xs 00000000 07:00 543360
/var/cache/fontconfig/b5a4f3f568a71026ccdc6a3a51afa9b4-x86.cache-2
b4976000-b4977000 r-xs 00000000 07:00 543359
/var/cache/fontconfig/2561679576a9c7fd2ce41d281d4e00d1-x86.cache-2
b4977000-b4978000 r-xs 00000000 07:00 543358
/var/cache/fontconfig/b8613a33de00eecd32d5a94c3c617829-x86.cache-2
b4978000-b497b000 r-xs 00000000 07:00 543357
/var/cache/fontconfig/b21a91cee725896328b8cee8091cf747-x86.cache-2
b497b000-b4980000 r-xs 00000000 07:00 543356
/var/cache/fontconfig/fd9416c4b92f07c6f59a3a8cf496e9dc-x86.cache-2
b4980000-b4982000 r-xs 00000000 07:00 543355
/var/cache/fontconfig/059138ec877db160474b4d5de1248d14-x86.cache-2
b4982000-b4983000 r-xs 00000000 07:00 543354
/var/cache/fontconfig/f5a93ac943883aa0fd9a7bfe0f6ec3c1-x86.cache-2
b4983000-b4985000 r-xs 00000000 07:00 543353
/var/cache/fontconfig/118d8d5311348bbdf5fe3b106d7c13d4-x86.cache-2
b4985000-b4986000 r-xs 00000000 07:00 543352
/var/cache/fontconfig/a1131b7be650f9abae4907495aa5815d-x86.cache-2
b4986000-b498b000 r-xs 00000000 07:00 543351
/var/cache/fontconfig/8ab5f685cd6d8ba67c37c908faf08172-x86.cache-2
b498b000-b498f000 r-xs 00000000 07:00 543350
/var/cache/fontconfig/0f32d3adc6a232110812e17374eaa446-x86.cache-2
b498f000-b4991000 r-xs 00000000 07:00 543349
/var/cache/fontconfig/7b4a97c10f6c0166998ddfa1cf7392fb-x86.cache-2
b4991000-b4994000 r-xs 00000000 07:00 543348
/var/cache/fontconfig/61c830dfac3fd78a12654da5e9ba3f56-x86.cache-2
b4994000-b4995000 r-xs 00000000 07:00 543347
/var/cache/fontconfig/e0f9e95429e756d56293ed4d63866094-x86.cache-2
b4995000-b4997000 r-xs 00000000 07:00 543346
/var/cache/fontconfig/4123634e9c08547d899d0aaff05ebe69-x86.cache-2
b4997000-b499b000 r-xs 00000000 07:00 543345
/var/cache/fontconfig/142ecfc435bad6f1fbc2648c1119d5eb-x86.cache-2
b499b000-b49a1000 r-xs 00000000 07:00 543344
/var/cache/fontconfig/102e5142c2e9e50c5e8ece26694a2dad-x86.cache-2
b49a1000-b49a2000 r-xs 00000000 07:00 543343
/var/cache/fontconfig/92a571655fb1c0ec1c4d6f496220600a-x86.cache-2
b49a2000-b49aa000 r-xs 00000000 07:00 543342
/var/cache/fontconfig/a960c40fc9306f090224a04585f8a963-x86.cache-2
b49aa000-b49ac000 r-xs 00000000 07:00 543341
/var/cache/fontconfig/9404ff413c67fc2a1526fd14eb4163a8-x86.cache-2
b49ac000-b49af000 r-xs 00000000 07:00 543340
/var/cache/fontconfig/b3fedf7c409f006ca1a6fceffceb77cf-x86.cache-2
b49af000-b49b1000 r-xs 00000000 07:00 542072
/var/cache/fontconfig/6330322105e0c4105d7c7a6ea2974107-x86.cache-2
b49b1000-b49c3000 r-xp 00000000 07:00 317075
/usr/lib/gtk-2.0/2.10.0/engines/libubuntulooks.so
b49c3000-b49c4000 rwxp 00011000 07:00 317075
/usr/lib/gtk-2.0/2.10.0/engines/libubuntulooks.so
b49c4000-b49c5000 r-xp 00000000 07:00 232335 /usr/lib/gconv/ISO8859-1.so
b49c5000-b49c7000 rwxp 00000000 07:00 232335 /usr/lib/gconv/ISO8859-1.so
b49c7000-b4a9e000 r-xp 00000000 07:00 263580
/usr/lib/locale/en_US.utf8/LC_COLLATE
b4a9e000-b4abc000 r-xp 00000000 07:00 233951 /usr/lib/libexpat.so.1.0.0
b4abc000-b4abe000 rwxp 0001d000 07:00 233951 /usr/lib/libexpat.so.1.0.0
b4abe000-b4ae0000 r-xp 00000000 07:00 233665 /usr/lib/libpng12.so.0.15.0
b4ae0000-b4ae1000 rwxp 00021000 07:00 233665 /usr/lib/libpng12.so.0.15.0
b4ae1000-b4af4000 r-xp 00000000 07:00 231781 /usr/lib/libz.so.1.2.3
b4af4000-b4af5000 rwxp 00012000 07:00 231781 /usr/lib/libz.so.1.2.3
b4af5000-b4b5d000 r-xp 00000000 07:00 233445 /usr/lib/libfreetype.so.6.3.10
b4b5d000-b4b60000 rwxp 00068000 07:00 233445 /usr/lib/libfreetype.so.6.3.10
b4b60000-b4b8a000 r-xp 00000000 07:00 234407
/usr/lib/libpangoft2-1.0.so.0.1600.2
b4b8a000-b4b8b000 rwxp 0002a000 07:00 234407
/usr/lib/libpangoft2-1.0.so.0.1600.2
b4b8b000-b4b90000 r-xp 00000000 07:00 234098 /usr/lib/libXrandr.so.2.1.0
b4b90000-b4b91000 rwxp 00005000 07:00 234098 /usr/lib/libXrandr.so.2.1.0
b4b91000-b4b93000 r-xp 00000000 07:00 234050 /usr/lib/libXinerama.so.1.0.0
b4b93000-b4b94000 rwxp 00001000 07:00 234050 /usr/lib/libXinerama.so.1.0.0
b4b94000-b4bb7000 r-xp 00000000 07:00 233999 /usr/lib/libfontconfig.so.1.2.0
b4bb7000-b4bbf000 rwxp 00023000 07:00 233999 /usr/lib/libfontconfig.so.1.2.0
b4bbf000-b4c2d000 r-xp 00000000 07:00 234388 /usr/lib/libcairo.so.2.11.1
b4c2d000-b4c2f000 rwxp 0006d000 07:00 234388 /usr/lib/libcairo.so.2.11.1
b4c2f000-b4cc3000 r-xp 00000000 07:00 234357 /usr/lib/libglib-2.0.so.0.1200.11
b4cc3000-b4cc4000 rwxp 00093000 07:00 234357 /usr/lib/libglib-2.0.so.0.1200.11
b4cc4000-b4cc6000 r-xp 00000000 07:00 234359
/usr/lib/libgmodule-2.0.so.0.1200.11
b4cc6000-b4cc7000 rwxp 00002000 07:00 234359
/usr/lib/libgmodule-2.0.so.0.1200.11
b4cc7000-b4d00000 r-xp 00000000 07:00 234358
/usr/lib/libgobject-2.0.so.0.1200.11
b4d00000-b4d01000 rwxp 00039000 07:00 234358
/usr/lib/libgobject-2.0.so.0.1200.11
b4d01000-b4d1a000 r-xp 00000000 07:00 234365 /usr/lib/libatk-1.0.so.0.1809.1
b4d1a000-b4d1c000 rwxp 00018000 07:00 234365 /usr/lib/libatk-1.0.so.0.1809.1
b4d1c000-b4d58000 r-xp 00000000 07:00 234405 /usr/lib/libpango-1.0.so.0.1600.2
b4d58000-b4d5a000 rwxp 0003b000 07:00 234405 /usr/lib/libpango-1.0.so.0.1600.2
b4d5a000-b4d61000 r-xp 00000000 07:00 234406
/usr/lib/libpangocairo-1.0.so.0.1600.2
b4d61000-b4d62000 rwxp 00007000 07:00 234406
/usr/lib/libpangocairo-1.0.so.0.1600.2
b4d62000-b4de5000 r-xp 00000000 07:00 234436
/usr/lib/libgdk-x11-2.0.so.0.1000.11
b4de5000-b4de8000 rwxp 00083000 07:00 234436
/usr/lib/libgdk-x11-2.0.so.0.1000.11
b4de8000-b4dfe000 r-xp 00000000 07:00 234435
/usr/lib/libgdk_pixbuf-2.0.so.0.1000.11
b4dfe000-b4dff000 rwxp 00015000 07:00 234435
/usr/lib/libgdk_pixbuf-2.0.so.0.1000.11
b4dff000-b5150000 r-xp 00000000 07:00 234437
/usr/lib/libgtk-x11-2.0.so.0.1000.11
b5150000-b5156000 rwxp 00351000 07:00 234437
/usr/lib/libgtk-x11-2.0.so.0.1000.11
b5156000-b5157000 rwxp b5156000 00:00 0
b5157000-b515a000 rwxp b5157000 00:00 0
b515a000-b51a8000 rwxp b515a000 00:00 0
b51a8000-b51ab000 ---p b51a8000 00:00 0
b51ab000-b51f9000 rwxp b51ab000 00:00 0
b51f9000-b51fc000 ---p b51f9000 00:00 0
b51fc000-b524a000 rwxp b51fc000 00:00 0
b524a000-b524d000 ---p b524a000 00:00 0
b524d000-b529b000 rwxp b524d000 00:00 0
b529b000-b5319000 r-xp 00000000 07:00 482178
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libfontmanager.so
b5319000-b5323000 rwxp 0007e000 07:00 482178
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libfontmanager.so
b5323000-b5328000 rwxp b5323000 00:00 0
b5328000-b5415000 r-xp 00000000 07:00 233943 /usr/lib/libX11.so.6.2.0
b5415000-b5419000 rwxp 000ed000 07:00 233943 /usr/lib/libX11.so.6.2.0
b5419000-b54df000 r-xp 00000000 07:00 482175
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libmlib_image.so
b54df000-b54e0000 rwxp 000c5000 07:00 482175
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libmlib_image.so
b54e0000-b555b000 r-xp 00000000 07:00 482176
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libawt.so
b555b000-b5562000 rwxp 0007b000 07:00 482176
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libawt.so
b5562000-b5586000 rwxp b5562000 00:00 0
b5586000-b5700000 r-xs 02c68000 07:00 482218
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/rt.jar
b5700000-b573b000 rwxp b5700000 00:00 0
b573b000-b5800000 ---p b573b000 00:00 0
b5800000-b5804000 r-xp 00000000 07:00 233949 /usr/lib/libXfixes.so.3.1.0
b5804000-b5805000 rwxp 00003000 07:00 233949 /usr/lib/libXfixes.so.3.1.0
b5805000-b580c000 r-xp 00000000 07:00 234001 /usr/lib/libXrender.so.1.3.0
b580c000-b580d000 rwxp 00006000 07:00 234001 /usr/lib/libXrender.so.1.3.0
b580d000-b5815000 r-xp 00000000 07:00 234176 /usr/lib/libXcursor.so.1.0.2
b5815000-b5816000 rwxp 00007000 07:00 234176 /usr/lib/libXcursor.so.1.0.2
b5816000-b581a000 r-xp 00000000 07:00 233941 /usr/lib/libXdmcp.so.6.0.0
b581a000-b581b000 rwxp 00003000 07:00 233941 /usr/lib/libXdmcp.so.6.0.0
b581b000-b581d000 r-xp 00000000 07:00 233939 /usr/lib/libXau.so.6.0.0
b581d000-b581e000 rwxp 00001000 07:00 233939 /usr/lib/libXau.so.6.0.0
b581e000-b5825000 r-xp 00000000 07:00 234037 /usr/lib/libXi.so.6.0.0
b5825000-b5826000 rwxp 00006000 07:00 234037 /usr/lib/libXi.so.6.0.0
b5826000-b582a000 r-xp 00000000 07:00 234052 /usr/lib/libXtst.so.6.1.0
b582a000-b582b000 rwxp 00003000 07:00 234052 /usr/lib/libXtst.so.6.1.0
b582b000-b5838000 r-xp 00000000 07:00 233945 /usr/lib/libXext.so.6.4.0
b5838000-b5839000 rwxp 0000d000 07:00 233945 /usr/lib/libXext.so.6.4.0
b5839000-b583b000 r-xs 00000000 07:00 542065
/var/cache/fontconfig/beeeeb3dfe132a8a0633a017c99ce0c0-x86.cache-2
b583b000-b583c000 r-xp 00000000 07:00 263578
/usr/lib/locale/en_US.utf8/LC_NUMERIC
b583c000-b583d000 r-xp 00000000 07:00 263579 /usr/lib/locale/en_US.utf8/LC_TIME
b583d000-b583e000 r-xp 00000000 07:00 263581
/usr/lib/locale/en_US.utf8/LC_MONETARY
b583e000-b583f000 r-xp 00000000 07:00 263583
/usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES
b583f000-b5840000 r-xp 00000000 07:00 263584 /usr/lib/locale/en_US.utf8/LC_PAPER
b5840000-b5841000 r-xp 00000000 07:00 263585 /usr/lib/locale/en_US.utf8/LC_NAME
b5841000-b5842000 r-xp 00000000 07:00 263586
/usr/lib/locale/en_US.utf8/LC_ADDRESS
b5842000-b5843000 r-xp 00000000 07:00 263587
/usr/lib/locale/en_US.utf8/LC_TELEPHONE
b5843000-b5844000 r-xp 00000000 07:00 263588
/usr/lib/locale/en_US.utf8/LC_MEASUREMENT
b5844000-b5882000 r-xp 00000000 07:00 495870
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
b5882000-b5885000 rwxp 0003d000 07:00 495870
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
b5885000-b58b5000 rwxp b5885000 00:00 0
b58b5000-b58bf000 r-xs 000fb000 07:01 61249
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/jogl.jar
b58bf000-b58c0000 ---p b58bf000 00:00 0
b58c0000-b5940000 rwxp b58c0000 00:00 0
b5940000-b5943000 ---p b5940000 00:00 0
b5943000-b5991000 rwxp b5943000 00:00 0
b5991000-b5994000 ---p b5991000 00:00 0
b5994000-b5a12000 rwxp b5994000 00:00 0
b5a12000-b5a15000 ---p b5a12000 00:00 0
b5a15000-b5a63000 rwxp b5a15000 00:00 0
b5a63000-b5a6a000 r-xs 00000000 07:00 231785 /usr/lib/gconv/gconv-modules.cache
b5a6a000-b5aa5000 r-xp 00000000 07:00 263577 /usr/lib/locale/en_US.utf8/LC_CTYPE
b5aa5000-b5aa8000 ---p b5aa5000 00:00 0
b5aa8000-b5af6000 rwxp b5aa8000 00:00 0
b5af6000-b5af9000 ---p b5af6000 00:00 0
b5af9000-b5b47000 rwxp b5af9000 00:00 0
b5b47000-b5b48000 ---p b5b47000 00:00 0
b5b48000-b5bdb000 rwxp b5b48000 00:00 0
b5bdb000-b5bf5000 rwxp b5bdb000 00:00 0
b5bf5000-b5bf8000 rwxp b5bf5000 00:00 0
b5bf8000-b5c13000 rwxp b5bf8000 00:00 0
b5c13000-b5c14000 rwxp b5c13000 00:00 0
b5c14000-b5c15000 rwxp b5c14000 00:00 0
b5c15000-b5c18000 rwxp b5c15000 00:00 0
b5c18000-b5c33000 rwxp b5c18000 00:00 0
b5c33000-b5c39000 rwxp b5c33000 00:00 0
b5c39000-b5c53000 rwxp b5c39000 00:00 0
b5c53000-b5c62000 rwxp b5c53000 00:00 0
b5c62000-b5cde000 rwxp b5c62000 00:00 0
b5cde000-b5dde000 rwxp b5cde000 00:00 0
b5dde000-b7cde000 rwxp b5dde000 00:00 0
b7cde000-b7ced000 r-xp 00000000 07:00 482161
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libzip.so
b7ced000-b7cef000 rwxp 0000e000 07:00 482161
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libzip.so
b7cef000-b7d12000 r-xp 00000000 07:00 482158
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjava.so
b7d12000-b7d14000 rwxp 00023000 07:00 482158
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjava.so
b7d14000-b7d1f000 r-xp 00000000 07:00 482157
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libverify.so
b7d1f000-b7d20000 rwxp 0000b000 07:00 482157
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libverify.so
b7d20000-b7d29000 r-xp 00000000 07:00 360610
/lib/tls/i686/cmov/libnss_files-2.5.so
b7d29000-b7d2b000 rwxp 00008000 07:00 360610
/lib/tls/i686/cmov/libnss_files-2.5.so
b7d2b000-b7d33000 r-xp 00000000 07:00 360613
/lib/tls/i686/cmov/libnss_nis-2.5.so
b7d33000-b7d35000 rwxp 00007000 07:00 360613
/lib/tls/i686/cmov/libnss_nis-2.5.so
b7d35000-b7d3c000 r-xp 00000000 07:00 360608
/lib/tls/i686/cmov/libnss_compat-2.5.so
b7d3c000-b7d3e000 rwxp 00006000 07:00 360608
/lib/tls/i686/cmov/libnss_compat-2.5.so
b7d3e000-b7d51000 r-xp 00000000 07:00 360607 /lib/tls/i686/cmov/libnsl-2.5.so
b7d51000-b7d53000 rwxp 00012000 07:00 360607 /lib/tls/i686/cmov/libnsl-2.5.so
b7d53000-b7d55000 rwxp b7d53000 00:00 0
b7d55000-b7d56000 r-xp 00000000 07:00 263589
/usr/lib/locale/en_US.utf8/LC_IDENTIFICATION
b7d56000-b7d58000 r-xs 0005e000 07:01 47390
/home/adam/javalibs/vecmath/vecmath/build/debug/lib/ext/vecmath.jar
b7d58000-b7d60000 rwxs 00000000 07:00 40737 /tmp/hsperfdata_adam/20461
b7d60000-b7d67000 r-xp 00000000 07:00 360621 /lib/tls/i686/cmov/librt-2.5.so
b7d67000-b7d69000 rwxp 00006000 07:00 360621 /lib/tls/i686/cmov/librt-2.5.so
b7d69000-b7d6c000 ---p b7d69000 00:00 0
b7d6c000-b7dba000 rwxp b7d6c000 00:00 0
b7dba000-b7ddf000 r-xp 00000000 07:00 360605 /lib/tls/i686/cmov/libm-2.5.so
b7ddf000-b7de1000 rwxp 00024000 07:00 360605 /lib/tls/i686/cmov/libm-2.5.so
b7de1000-b7de2000 rwxp b7de1000 00:00 0
b7de2000-b7f1d000 r-xp 00000000 07:00 360600 /lib/tls/i686/cmov/libc-2.5.so
b7f1d000-b7f1e000 r-xp 0013b000 07:00 360600 /lib/tls/i686/cmov/libc-2.5.so
b7f1e000-b7f20000 rwxp 0013c000 07:00 360600 /lib/tls/i686/cmov/libc-2.5.so
b7f20000-b7f23000 rwxp b7f20000 00:00 0
b7f23000-b7f25000 r-xp 00000000 07:00 360604 /lib/tls/i686/cmov/libdl-2.5.so
b7f25000-b7f27000 rwxp 00001000 07:00 360604 /lib/tls/i686/cmov/libdl-2.5.so
b7f27000-b7f2e000 r-xp 00000000 07:00 482160
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/jli/libjli.so
b7f2e000-b7f30000 rwxp 00006000 07:00 482160
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/jli/libjli.so
b7f30000-b7f31000 rwxp b7f30000 00:00 0
b7f31000-b7f44000 r-xp 00000000 07:00 360618
/lib/tls/i686/cmov/libpthread-2.5.so
b7f44000-b7f46000 rwxp 00013000 07:00 360618
/lib/tls/i686/cmov/libpthread-2.5.so
b7f46000-b7f48000 rwxp b7f46000 00:00 0
b7f48000-b7f4a000 r-xs 00003000 07:01 61248
/home/adam/javalibs/JOGL/jogl-1.1.1-rc3-linux-i586/lib/gluegen-rt.jar
b7f4a000-b7f50000 r-xp 00000000 07:00 481576
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/native_threads/libhpi.so
b7f50000-b7f51000 rwxp 00006000 07:00 481576
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/native_threads/libhpi.so
b7f51000-b7f52000 rwxp b7f51000 00:00 0
b7f52000-b7f53000 r-xp b7f52000 00:00 0
b7f53000-b7f55000 rwxp b7f53000 00:00 0
b7f55000-b7f6e000 r-xp 00000000 07:00 360463 /lib/ld-2.5.so
b7f6e000-b7f70000 rwxp 00019000 07:00 360463 /lib/ld-2.5.so
bfaaf000-bfac4000 rwxp bfaaf000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]

VM Arguments:
java_command: org.davincisoft.DaVinci $

{application.args}

Launcher Type: SUN_STANDARD

Environment Variables:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
USERNAME=adam
LD_LIBRARY_PATH=/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client:/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386:/usr/lib/jvm/java-6-sun-1.6.0.00/jre/../lib/i386
SHELL=/bin/bash
DISPLAY=:0.0

Signal Handlers:
SIGSEGV: [libjvm.so+0x3aea90], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x3aea90], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x304e70], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x304e70], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x304e70], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x306e80], sa_mask[0]=0x00000004, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR2: [libjvm.so+0x306e80], sa_mask[0]=0x00000004, sa_flags=0x10000004

--------------- S Y S T E M ---------------

OS:4.0

uname:Linux 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686
libc:glibc 2.5 NPTL 2.5
rlimit: STACK 8192k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity
load average:2.09 1.47 1.32

CPU:total 1 family 6, cmov, cx8, fxsr, mmx, sse, sse2

Memory: 4k page, physical 507736k(5516k free), swap 488272k(394980k free)

vm_info: Java HotSpot(TM) Client VM (1.6.0-b105) for linux-x86, built on Nov 29
2006 01:24:38 by "java_re" with gcc 3.2.1-7a (J2SE release)
********************************************************************************



 Comments   
Comment by badapple [ 05/Aug/07 ]

To varify this you can down load Chris Campbell's Photo Cube example from his
blog at
(http://weblogs.java.net/blog/campbell/archive/2006/10/easy_2d3d_mixin.html),
which uses a GLJPanel.

Comment by kbr [ 06/Aug/07 ]

The two reported issues are likely different. The first does not use the Java 2D
/ OpenGL pipeline and is probably an application bug. The OpenGL state is
probably getting corrupted which is leading to GLX errors and ultimately
crashes. This can be diagnosed with the DebugGL.

The second may be a problem with the Java 2D / JOGL bridge and/or the Java 2D /
OpenGL pipeline, possibly driver-related. We are working with NVidia to address
regressions in the Java 2D / OpenGL pipeline caused by their most recent driver
release.

I would suggest you see if there is a more recent graphics driver available;
Intel's recent release of open-source Linux drivers for some of their integrated
chipsets may address some of these issues if applicable.

If you can provide a small and self-contained test case clearly illustrating a
bug in JOGL's OpenGL context management then please reopen this bug or file a
new one. Closing as "works for me".

Comment by badapple [ 07/Aug/07 ]

I am reopening this due to the fact that the last person did not test
thoroughly, and it shows up in your own demos, so I feel no need to supply a
test case. This shows up in the jogl-demos that use a GLJPanel and
demos.jgears.JGears crashes the JVM with the current release 1.1 and rc3 on
Ubuntu 7.04 with JDK6. These work fine on windows. Here is the crash log.
**********************************************************************************
#

  1. An unexpected error has been detected by Java Runtime Environment:
    #
  2. SIGSEGV (0xb) at pc=0xb54ef317, pid=12105, tid=2966633360
    #
  3. Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode, sharing)
  4. Problematic frame:
  5. C [libX11.so.6+0x32317] XQueryExtension+0x17
    #
  6. If you would like to submit a bug report, please visit:
  7. http://java.sun.com/webapps/bugreport/crash.jsp
    #

--------------- T H R E A D ---------------

Current thread (0x08393400): JavaThread "AWT-EventQueue-0" [_thread_in_native,
id=12190]

siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x000004d0

Registers:
EAX=0xb516e0ad, EBX=0xb55aab2c, ECX=0x082f5e08, EDX=0x00000000
ESP=0xb0d320e0, EBP=0xb0d32128, ESI=0x00000000, EDI=0x00000000
EIP=0xb54ef317, CR2=0x000004d0, EFLAGS=0x00010282

Top of Stack: (sp=0xb0d320e0)
0xb0d320e0: b5d536f0 084892e0 08393628 08393650
0xb0d320f0: b0d321a4 08393400 b0d32294 b0d3211c
0xb0d32100: 063057d8 b0d32274 b0d32150 b0d321a4
0xb0d32110: 08393400 00000000 00000000 b55aab2c
0xb0d32120: 00000000 00000000 b0d32168 b54e3c6b
0xb0d32130: 00000000 b516e0ad b0d32150 b0d32154
0xb0d32140: b0d32158 b7f8b120 08393400 b0d32168
0xb0d32150: b7eb660e b7f8b120 00000010 b55bb158

Instructions: (pc=0xb54ef317)
0xb54ef307: ec 3c 8b 7d 08 e8 36 51 fe ff 81 c3 1b b8 0b 00
0xb54ef317: 8b 87 d0 04 00 00 85 c0 74 05 89 3c 24 ff 10 8b

Stack: [0xb0ce3000,0xb0d34000), sp=0xb0d320e0, free space=316k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libX11.so.6+0x32317] XQueryExtension+0x17
C [libX11.so.6+0x26c6b] XInitExtension+0x3b
C [libXext.so.6+0xc433] XextAddDisplay+0x53
C [libGL.so.1+0x20704]
C [libGL.so.1+0x20f64] __glXInitialize+0x14
C [libGL.so.1+0x21f6f] __glXSetupForCommand+0x3f
C [libGL.so.1+0x2020b]
C [libjogl.so+0x48c60] Java_com_sun_opengl_impl_x11_GLX_glXDestroyContext__JJ+0x3e
j com.sun.opengl.impl.x11.GLX.glXDestroyContext(JJ)V+0
j com.sun.opengl.impl.x11.X11GLContext.destroyImpl()V+78
j com.sun.opengl.impl.GLContextImpl.destroy()V+60
j javax.media.opengl.GLJPanel.handleReshape()V+425
j javax.media.opengl.GLJPanel.paintComponent(Ljava/awt/Graphics;)V+27
j demos.jgears.JGears.paintComponent(Ljava/awt/Graphics;)V+2
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+269
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+301
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+301
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+301
j javax.swing.JLayeredPane.paint(Ljava/awt/Graphics;)V+73
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paintToOffscreen(Ljava/awt/Graphics;IIIIII)V+72
j
javax.swing.BufferStrategyPaintManager.paint(Ljavax/swing/JComponent;Ljavax/swing/JComponent;Ljava/awt/Graphics;IIII)Z+157
j
javax.swing.RepaintManager.paint(Ljavax/swing/JComponent;Ljavax/swing/JComponent;Ljava/awt/Graphics;IIII)V+52
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+204
j
java.awt.GraphicsCallback$PaintCallback.run(Ljava/awt/Component;Ljava/awt/Graphics;)V+2
j
sun.awt.SunGraphicsCallback.runOneComponent(Ljava/awt/Component;Ljava/awt/Rectangle;Ljava/awt/Graphics;Ljava/awt/Shape;I)V+155
j
sun.awt.SunGraphicsCallback.runComponents([Ljava/awt/Component;Ljava/awt/Graphics;I)V+104
j java.awt.Container.paint(Ljava/awt/Graphics;)V+62
j javax.swing.RepaintManager.paintDirtyRegions(Ljava/util/Map;)V+245
j javax.swing.RepaintManager.paintDirtyRegions()V+46
j com.sun.opengl.util.Animator$1.run()V+371
j java.awt.event.InvocationEvent.dispatch()V+11
j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+26
j java.awt.EventDispatchThread.pumpOneEventForFilters(I)Z+156
j
java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+30
j
java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j java.awt.EventDispatchThread.run()V+9
v ~StubRoutines::call_stub
V [libjvm.so+0x20967d]
V [libjvm.so+0x3057d8]
V [libjvm.so+0x208f90]
V [libjvm.so+0x20901d]
V [libjvm.so+0x279215]
V [libjvm.so+0x38035f]
V [libjvm.so+0x3066b3]
C [libpthread.so.0+0x531b]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.sun.opengl.impl.x11.GLX.glXDestroyContext(JJ)V+0
j com.sun.opengl.impl.x11.X11GLContext.destroyImpl()V+78
j com.sun.opengl.impl.GLContextImpl.destroy()V+60
j javax.media.opengl.GLJPanel.handleReshape()V+425
j javax.media.opengl.GLJPanel.paintComponent(Ljava/awt/Graphics;)V+27
j demos.jgears.JGears.paintComponent(Ljava/awt/Graphics;)V+2
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+269
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+301
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+301
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+301
j javax.swing.JLayeredPane.paint(Ljava/awt/Graphics;)V+73
j javax.swing.JComponent.paintChildren(Ljava/awt/Graphics;)V+473
j javax.swing.JComponent.paintToOffscreen(Ljava/awt/Graphics;IIIIII)V+72
j
javax.swing.BufferStrategyPaintManager.paint(Ljavax/swing/JComponent;Ljavax/swing/JComponent;Ljava/awt/Graphics;IIII)Z+157
j
javax.swing.RepaintManager.paint(Ljavax/swing/JComponent;Ljavax/swing/JComponent;Ljava/awt/Graphics;IIII)V+52
j javax.swing.JComponent.paint(Ljava/awt/Graphics;)V+204
j
java.awt.GraphicsCallback$PaintCallback.run(Ljava/awt/Component;Ljava/awt/Graphics;)V+2
j
sun.awt.SunGraphicsCallback.runOneComponent(Ljava/awt/Component;Ljava/awt/Rectangle;Ljava/awt/Graphics;Ljava/awt/Shape;I)V+155
j
sun.awt.SunGraphicsCallback.runComponents([Ljava/awt/Component;Ljava/awt/Graphics;I)V+104
j java.awt.Container.paint(Ljava/awt/Graphics;)V+62
j javax.swing.RepaintManager.paintDirtyRegions(Ljava/util/Map;)V+245
j javax.swing.RepaintManager.paintDirtyRegions()V+46
j com.sun.opengl.util.Animator$1.run()V+371
j java.awt.event.InvocationEvent.dispatch()V+11
j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+26
j java.awt.EventDispatchThread.pumpOneEventForFilters(I)Z+156
j
java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+30
j
java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j java.awt.EventDispatchThread.run()V+9
v ~StubRoutines::call_stub

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
=>0x08393400 JavaThread "AWT-EventQueue-0" [_thread_in_native, id=12190]
0x08058c00 JavaThread "DestroyJavaVM" [_thread_blocked, id=12112]
0x082f6000 JavaThread "Thread-2" [_thread_blocked, id=12172]
0x080d8000 JavaThread "AWT-Shutdown" [_thread_blocked, id=12164]
0x082e6400 JavaThread "AWT-XAWT" daemon [_thread_blocked, id=12149]
0x082bd400 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=12145]
0x0808dc00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=12126]
0x0808c400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=12125]
0x0808b000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=12124]
0x08082000 JavaThread "Finalizer" daemon [_thread_blocked, id=12123]
0x08081000 JavaThread "Reference Handler" daemon [_thread_blocked, id=12122]

Other Threads:
0x08077800 VMThread [id=12121]
0x0808f400 WatcherThread [id=12127]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
def new generation total 960K, used 124K [0x8c050000, 0x8c150000, 0x8c530000)
eden space 896K, 12% used [0x8c050000, 0x8c06b508, 0x8c130000)
from space 64K, 23% used [0x8c130000, 0x8c133d50, 0x8c140000)
to space 64K, 0% used [0x8c140000, 0x8c140000, 0x8c150000)
tenured generation total 4096K, used 948K [0x8c530000, 0x8c930000, 0x90050000)
the space 4096K, 23% used [0x8c530000, 0x8c61d3f8, 0x8c61d400, 0x8c930000)
compacting perm gen total 12288K, used 2676K [0x90050000, 0x90c50000, 0x94050000)
the space 12288K, 21% used [0x90050000, 0x902ed218, 0x902ed400, 0x90c50000)
ro space 8192K, 73% used [0x94050000, 0x9462e548, 0x9462e600, 0x94850000)
rw space 12288K, 57% used [0x94850000, 0x94f416c0, 0x94f41800, 0x95450000)

Dynamic libraries:
06000000-06412000 r-xp 00000000 07:00 400167
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/libjvm.so
06412000-0642b000 rwxp 00411000 07:00 400167
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/libjvm.so
0642b000-0684a000 rwxp 0642b000 00:00 0
08048000-08052000 r-xp 00000000 07:00 400141
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/bin/java
08052000-08053000 rwxp 00009000 07:00 400141
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/bin/java
08053000-08727000 rwxp 08053000 00:00 0 [heap]
8c050000-8c150000 rwxp 8c050000 00:00 0
8c150000-8c530000 rwxp 8c150000 00:00 0
8c530000-8c930000 rwxp 8c530000 00:00 0
8c930000-90050000 rwxp 8c930000 00:00 0
90050000-90c50000 rwxp 90050000 00:00 0
90c50000-94050000 rwxp 90c50000 00:00 0
94050000-9462f000 r-xs 00001000 07:00 400280
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
9462f000-94850000 rwxp 9462f000 00:00 0
94850000-94f42000 rwxp 005e0000 07:00 400280
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
94f42000-95450000 rwxp 94f42000 00:00 0
95450000-95529000 rwxp 00cd2000 07:00 400280
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
95529000-95850000 rwxp 95529000 00:00 0
95850000-95854000 r-xs 00dab000 07:00 400280
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client/classes.jsa
95854000-95c50000 rwxp 95854000 00:00 0
b0ce3000-b0ce6000 ---p b0ce3000 00:00 0
b0ce6000-b0d75000 rwxp b0ce6000 00:00 0
b0d75000-b34b5000 rwxs ca0c0000 00:0d 17246 /dev/dri/card0
b34b5000-b3af5000 rwxs cc800000 00:0d 17246 /dev/dri/card0
b3af5000-b4135000 rwxs cd000000 00:0d 17246 /dev/dri/card0
b4135000-b4775000 rwxs 28004000 00:0d 17246 /dev/dri/card0
b4775000-b4db5000 rwxs c0020000 00:0d 17246 /dev/dri/card0
b4db5000-b4dd3000 r-xp 00000000 07:00 102879 /usr/lib/libexpat.so.1.0.0
b4dd3000-b4dd5000 rwxp 0001d000 07:00 102879 /usr/lib/libexpat.so.1.0.0
b4ddf000-b501b000 r-xp 00000000 07:00 383563 /usr/lib/dri/i915_dri.so
b501b000-b502a000 rwxp 0023c000 07:00 383563 /usr/lib/dri/i915_dri.so
b502a000-b5035000 rwxp b502a000 00:00 0
b5035000-b5110000 r-xp 00000000 07:01 46555
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/libjogl.so
b5110000-b5111000 rwxp 000da000 07:01 46555
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/libjogl.so
b5111000-b5119000 r-xp 00000000 07:00 102939 /usr/lib/libdrm.so.2.3.0
b5119000-b511a000 rwxp 00008000 07:00 102939 /usr/lib/libdrm.so.2.3.0
b511a000-b511e000 r-xp 00000000 07:00 102986 /usr/lib/libXxf86vm.so.1.0.0
b511e000-b511f000 rwxp 00003000 07:00 102986 /usr/lib/libXxf86vm.so.1.0.0
b511f000-b517c000 r-xp 00000000 07:00 573744 /usr/lib/libGL.so.1.2
b517c000-b517e000 rwxp 0005d000 07:00 573744 /usr/lib/libGL.so.1.2
b517e000-b517f000 rwxp b517e000 00:00 0
b5182000-b5184000 rwxs e0843000 00:0d 17246 /dev/dri/card0
b5184000-b5186000 r-xp 00000000 07:01 46556
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/libjogl_awt.so
b5186000-b5187000 rwxp 00001000 07:01 46556
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/libjogl_awt.so
b5187000-b5188000 r-xp 00000000 07:00 400205
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjawt.so
b5188000-b5189000 rwxp 00000000 07:00 400205
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjawt.so
b5189000-b51d6000 rwxs 00000000 00:08 3801103 /SYSV00000000 (deleted)
b51d6000-b51d9000 ---p b51d6000 00:00 0
b51d9000-b5227000 rwxp b51d9000 00:00 0
b5227000-b522a000 rwxp b5227000 00:00 0
b522a000-b5278000 rwxp b522a000 00:00 0
b5278000-b528b000 r-xp 00000000 07:00 400180
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnet.so
b528b000-b528c000 rwxp 00013000 07:00 400180
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnet.so
b528c000-b528f000 ---p b528c000 00:00 0
b528f000-b52dd000 rwxp b528f000 00:00 0
b52dd000-b530b000 r-xp 00000000 07:00 400200
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjpeg.so
b530b000-b530c000 rwxp 0002e000 07:00 400200
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjpeg.so
b530c000-b5360000 r-xp 00000000 07:00 400201
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libcmm.so
b5360000-b5363000 rwxp 00054000 07:00 400201
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libcmm.so
b5363000-b5366000 ---p b5363000 00:00 0
b5366000-b53b4000 rwxp b5366000 00:00 0
b53b4000-b53b8000 r-xp 00000000 07:00 102877 /usr/lib/libXfixes.so.3.1.0
b53b8000-b53b9000 rwxp 00003000 07:00 102877 /usr/lib/libXfixes.so.3.1.0
b53b9000-b53c0000 r-xp 00000000 07:00 102929 /usr/lib/libXrender.so.1.3.0
b53c0000-b53c1000 rwxp 00006000 07:00 102929 /usr/lib/libXrender.so.1.3.0
b53c1000-b53c9000 r-xp 00000000 07:00 103104 /usr/lib/libXcursor.so.1.0.2
b53c9000-b53ca000 rwxp 00007000 07:00 103104 /usr/lib/libXcursor.so.1.0.2
b53ca000-b53cd000 ---p b53ca000 00:00 0
b53cd000-b541b000 rwxp b53cd000 00:00 0
b541b000-b5499000 r-xp 00000000 07:00 400199
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libfontmanager.so
b5499000-b54a3000 rwxp 0007e000 07:00 400199
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libfontmanager.so
b54a3000-b54a8000 rwxp b54a3000 00:00 0
b54a8000-b54ac000 r-xp 00000000 07:00 102869 /usr/lib/libXdmcp.so.6.0.0
b54ac000-b54ad000 rwxp 00003000 07:00 102869 /usr/lib/libXdmcp.so.6.0.0
b54ad000-b54af000 r-xp 00000000 07:00 102867 /usr/lib/libXau.so.6.0.0
b54af000-b54b0000 rwxp 00001000 07:00 102867 /usr/lib/libXau.so.6.0.0
b54b0000-b54b7000 r-xp 00000000 07:00 102965 /usr/lib/libXi.so.6.0.0
b54b7000-b54b8000 rwxp 00006000 07:00 102965 /usr/lib/libXi.so.6.0.0
b54b8000-b54bc000 r-xp 00000000 07:00 102980 /usr/lib/libXtst.so.6.1.0
b54bc000-b54bd000 rwxp 00003000 07:00 102980 /usr/lib/libXtst.so.6.1.0
b54bd000-b55aa000 r-xp 00000000 07:00 102871 /usr/lib/libX11.so.6.2.0
b55aa000-b55ae000 rwxp 000ed000 07:00 102871 /usr/lib/libX11.so.6.2.0
b55ae000-b55bb000 r-xp 00000000 07:00 102873 /usr/lib/libXext.so.6.4.0
b55bb000-b55bc000 rwxp 0000d000 07:00 102873 /usr/lib/libXext.so.6.4.0
b55bc000-b55bd000 r-xp 00000000 07:01 46554
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/libgluegen-rt.so
b55bd000-b55be000 rwxp 00000000 07:01 46554
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/libgluegen-rt.so
b55be000-b55c5000 r-xp 00000000 07:00 400181
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnio.so
b55c5000-b55c6000 rwxp 00006000 07:00 400181
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libnio.so
b55c6000-b5604000 r-xp 00000000 07:00 400194
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
b5604000-b5607000 rwxp 0003d000 07:00 400194
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
b5607000-b56cd000 r-xp 00000000 07:00 400190
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libmlib_image.so
b56cd000-b56ce000 rwxp 000c5000 07:00 400190
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libmlib_image.so
b56ce000-b5749000 r-xp 00000000 07:00 400191
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libawt.so
b5749000-b5750000 rwxp 0007b000 07:00 400191
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libawt.so
b5750000-b57a4000 rwxp b5750000 00:00 0
b57a4000-b591e000 r-xs 02c68000 07:00 400245
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/rt.jar
b591e000-b5920000 r-xs 0000b000 07:01 62318
/home/adam/dev/java/jogl-demos/lib/joal.jar
b5920000-b592b000 r-xs 000fa000 07:01 46553
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/jogl.jar
b592b000-b592c000 ---p b592b000 00:00 0
b592c000-b59ac000 rwxp b592c000 00:00 0
b59ac000-b59af000 ---p b59ac000 00:00 0
b59af000-b59fd000 rwxp b59af000 00:00 0
b59fd000-b5a00000 ---p b59fd000 00:00 0
b5a00000-b5a7e000 rwxp b5a00000 00:00 0
b5a7e000-b5a81000 ---p b5a7e000 00:00 0
b5a81000-b5acf000 rwxp b5a81000 00:00 0
b5acf000-b5ad6000 r-xs 00000000 07:00 100713 /usr/lib/gconv/gconv-modules.cache
b5ad6000-b5b11000 r-xp 00000000 07:00 132620 /usr/lib/locale/en_US.utf8/LC_CTYPE
b5b11000-b5b14000 ---p b5b11000 00:00 0
b5b14000-b5b62000 rwxp b5b14000 00:00 0
b5b62000-b5b65000 ---p b5b62000 00:00 0
b5b65000-b5bb3000 rwxp b5b65000 00:00 0
b5bb3000-b5bb4000 ---p b5bb3000 00:00 0
b5bb4000-b5c47000 rwxp b5bb4000 00:00 0
b5c47000-b5c61000 rwxp b5c47000 00:00 0
b5c61000-b5c64000 rwxp b5c61000 00:00 0
b5c64000-b5c7f000 rwxp b5c64000 00:00 0
b5c7f000-b5c80000 rwxp b5c7f000 00:00 0
b5c80000-b5c81000 rwxp b5c80000 00:00 0
b5c81000-b5c84000 rwxp b5c81000 00:00 0
b5c84000-b5c9f000 rwxp b5c84000 00:00 0
b5c9f000-b5ca5000 rwxp b5c9f000 00:00 0
b5ca5000-b5cbf000 rwxp b5ca5000 00:00 0
b5cbf000-b5cce000 rwxp b5cbf000 00:00 0
b5cce000-b5d4a000 rwxp b5cce000 00:00 0
b5d4a000-b5e3a000 rwxp b5d4a000 00:00 0
b5e3a000-b7d4a000 rwxp b5e3a000 00:00 0
b7d4a000-b7d59000 r-xp 00000000 07:00 400176
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libzip.so
b7d59000-b7d5b000 rwxp 0000e000 07:00 400176
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libzip.so
b7d5b000-b7d7e000 r-xp 00000000 07:00 400173
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjava.so
b7d7e000-b7d80000 rwxp 00023000 07:00 400173
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libjava.so
b7d80000-b7d8b000 r-xp 00000000 07:00 400172
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libverify.so
b7d8b000-b7d8c000 rwxp 0000b000 07:00 400172
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/libverify.so
b7d8c000-b7d95000 r-xp 00000000 07:00 131234
/lib/tls/i686/cmov/libnss_files-2.5.so
b7d95000-b7d97000 rwxp 00008000 07:00 131234
/lib/tls/i686/cmov/libnss_files-2.5.so
b7d97000-b7d9f000 r-xp 00000000 07:00 131237
/lib/tls/i686/cmov/libnss_nis-2.5.so
b7d9f000-b7da1000 rwxp 00007000 07:00 131237
/lib/tls/i686/cmov/libnss_nis-2.5.so
b7da1000-b7da8000 r-xp 00000000 07:00 131232
/lib/tls/i686/cmov/libnss_compat-2.5.so
b7da8000-b7daa000 rwxp 00006000 07:00 131232
/lib/tls/i686/cmov/libnss_compat-2.5.so
b7daa000-b7dbd000 r-xp 00000000 07:00 131231 /lib/tls/i686/cmov/libnsl-2.5.so
b7dbd000-b7dbf000 rwxp 00012000 07:00 131231 /lib/tls/i686/cmov/libnsl-2.5.so
b7dbf000-b7dc1000 rwxp b7dbf000 00:00 0
b7dc1000-b7dc3000 r-xs 00003000 07:01 46552
/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/gluegen-rt.jar
b7dc3000-b7dcb000 rwxs 00000000 07:00 606654 /tmp/hsperfdata_adam/12105
b7dcb000-b7dd2000 r-xp 00000000 07:00 131245 /lib/tls/i686/cmov/librt-2.5.so
b7dd2000-b7dd4000 rwxp 00006000 07:00 131245 /lib/tls/i686/cmov/librt-2.5.so
b7dd4000-b7dd7000 ---p b7dd4000 00:00 0
b7dd7000-b7e25000 rwxp b7dd7000 00:00 0
b7e25000-b7e4a000 r-xp 00000000 07:00 131229 /lib/tls/i686/cmov/libm-2.5.so
b7e4a000-b7e4c000 rwxp 00024000 07:00 131229 /lib/tls/i686/cmov/libm-2.5.so
b7e4c000-b7e4d000 rwxp b7e4c000 00:00 0
b7e4d000-b7f88000 r-xp 00000000 07:00 131224 /lib/tls/i686/cmov/libc-2.5.so
b7f88000-b7f89000 r-xp 0013b000 07:00 131224 /lib/tls/i686/cmov/libc-2.5.so
b7f89000-b7f8b000 rwxp 0013c000 07:00 131224 /lib/tls/i686/cmov/libc-2.5.so
b7f8b000-b7f8e000 rwxp b7f8b000 00:00 0
b7f8e000-b7f90000 r-xp 00000000 07:00 131228 /lib/tls/i686/cmov/libdl-2.5.so
b7f90000-b7f92000 rwxp 00001000 07:00 131228 /lib/tls/i686/cmov/libdl-2.5.so
b7f92000-b7f99000 r-xp 00000000 07:00 400175
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/jli/libjli.so
b7f99000-b7f9b000 rwxp 00006000 07:00 400175
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/jli/libjli.so
b7f9b000-b7f9c000 rwxp b7f9b000 00:00 0
b7f9c000-b7faf000 r-xp 00000000 07:00 131242
/lib/tls/i686/cmov/libpthread-2.5.so
b7faf000-b7fb1000 rwxp 00013000 07:00 131242
/lib/tls/i686/cmov/libpthread-2.5.so
b7fb1000-b7fb3000 rwxp b7fb1000 00:00 0
b7fb3000-b7fb4000 r-xs 00107000 07:01 62317
/home/adam/dev/java/jogl-demos/lib/joal-demos.jar
b7fb4000-b7fba000 r-xp 00000000 07:00 400161
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/native_threads/libhpi.so
b7fba000-b7fbb000 rwxp 00006000 07:00 400161
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/native_threads/libhpi.so
b7fbb000-b7fbc000 rwxp b7fbb000 00:00 0
b7fbc000-b7fbd000 r-xp b7fbc000 00:00 0
b7fbd000-b7fbf000 rwxp b7fbd000 00:00 0
b7fbf000-b7fd8000 r-xp 00000000 07:00 131087 /lib/ld-2.5.so
b7fd8000-b7fda000 rwxp 00019000 07:00 131087 /lib/ld-2.5.so
bfb93000-bfba8000 rwxp bfb93000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]

VM Arguments:
jvm_args: -Djava.library.path=/home/adam/javalibs/JOGL/jogl-1.1.0-linux-i586/lib/
java_command: demos.jgears.JGears
Launcher Type: SUN_STANDARD

Environment Variables:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
USERNAME=adam
LD_LIBRARY_PATH=/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/client:/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386:/usr/lib/jvm/java-6-sun-1.6.0.00/jre/../lib/i386
SHELL=/bin/bash
DISPLAY=:0.0

Signal Handlers:
SIGSEGV: [libjvm.so+0x3aea90], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x3aea90], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x304e70], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x304e70], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x304e70], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x306e80], sa_mask[0]=0x00000004, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x3068a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR2: [libjvm.so+0x306e80], sa_mask[0]=0x00000004, sa_flags=0x10000004

--------------- S Y S T E M ---------------

OS:4.0

uname:Linux 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686
libc:glibc 2.5 NPTL 2.5
rlimit: STACK 8192k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity
load average:2.36 1.19 0.86

CPU:total 1 family 6, cmov, cx8, fxsr, mmx, sse, sse2

Memory: 4k page, physical 507736k(6240k free), swap 488272k(394796k free)

vm_info: Java HotSpot(TM) Client VM (1.6.0-b105) for linux-x86, built on Nov 29
2006 01:24:38 by "java_re" with gcc 3.2.1-7a (J2SE release)

************************************************************************************





Generated at Tue Sep 01 15:35:04 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.