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

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

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

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



 Description   

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



 Comments   
Comment by eban [ 25/Feb/14 ]

Sorry, wrong bugtracker, please disregard/delete this ticket





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

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

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


 Description   

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



 Comments   
Comment by dekken [ 29/Nov/11 ]

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

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

Viola.

Comment by ranu [ 05/Dec/11 ]

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





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

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

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

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



 Description   

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

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

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






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

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 378

 Description   

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

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

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

{ ... }

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

TextureIO.newTextureData(myFile, false, null);

will throw this exception:

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






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

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

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

Operating System: Linux
Platform: Other


Issuezilla Id: 376

 Description   

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

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

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

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

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

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

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

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

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



 Comments   
Comment by merscwog [ 12/Jul/09 ]

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

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

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

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

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

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

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

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

Comment by merscwog [ 13/Jul/09 ]

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

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

OpenGL Warning: XGetVisualInfo returned 0 visuals for 40c35090

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

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

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

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

Comment by sgoethel [ 16/Jul/09 ]

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

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

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

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

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

Cheers, Sven

Comment by merscwog [ 16/Jul/09 ]

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

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

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

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

Comment by sgoethel [ 19/Jul/09 ]

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

Comment by merscwog [ 20/Jul/09 ]

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





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

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

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

Operating System: Mac OS X
Platform: Macintosh


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

 Description   

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

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

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



 Comments   
Comment by bsder [ 14/Jun/09 ]

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

Comment by bsder [ 14/Jun/09 ]

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





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

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

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

Operating System: All
Platform: All


Issuezilla Id: 374

 Description   

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



 Comments   
Comment by kbr [ 13/May/09 ]

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

Comment by kitfox [ 14/May/09 ]

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





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

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

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

Operating System: All
Platform: All


Issuezilla Id: 373

 Description   

The methods

CgGL.cgSetCompilerIncludeCallback
CgGL.cgSetCompilerIncludeString

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

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



 Comments   
Comment by kbr [ 01/May/09 ]

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





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

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

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

Operating System: All
Platform: All


Issuezilla Id: 372

 Description   

According to the OpenGL docs, the method

glDrawElementsInstancedEXT

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






[JOGL-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-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-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-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-362] calculated dimensions for MipMaps smaller than 16x16 Created: 06/Sep/08  Updated: 06/Sep/08

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 362

 Description   

Hello everybody!

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

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

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

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

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

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

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

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

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

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

I did some patch job to fix this.

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

/* Change

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

    else

    { curSize /= 4; }

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

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

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

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

best regards,
Dahie






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

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

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

Operating System: All
Platform: All


Issuezilla Id: 361

 Description   

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

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

This should be added in the TextRenderer Java doc.

Jean-Baptiste






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

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 360

 Description   

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



 Comments   
Comment by kbr [ 17/Aug/08 ]

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





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






Generated at Sun Aug 30 01:55:04 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.