Could you clear out your Java Web Start application cache, or just delete that application, and try again? I think the java.net servers are (once again) not reporting a correct time stamp for the jar files, so your system isn't downloading the latest version.

I am using ATI 9600 Pro. After clean up the cache, the previous message doesn't show up anymore, but this timeI got a new error message.

"Unable to set pixel format"

The same error message on both the latest driver from ATI and the old 4.6 driver.

Is this just with the new JRefract demo, or with all JOGL apps? Could you post a stack trace? Even better, could you run the app locally with the system property -Djogl.debug.GLContext specified and post all of the output? Thanks.

Is this just with the new JRefract demo, or with all JOGL apps? Could you post a stack trace? Even better, could you run the app locally with the system property -Djogl.debug.GLContext specified and post all of the output? Thanks.

net.java.games.jogl.GLException: Unable to set pixel format at net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext(WindowsGLContext.java:493) at net.java.games.jogl.impl.windows.WindowsOffscreenGLContext.create(WindowsOffscreenGLContext.java:181) at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:135) at net.java.games.jogl.impl.windows.WindowsOffscreenGLContext.makeCurrent(WindowsOffscreenGLContext.java:128) at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:250) at net.java.games.jogl.GLJPanel.reshape(GLJPanel.java:131) at java.awt.Component.setBounds(Component.java:1847) at java.awt.Component.resize(Component.java:1781) at java.awt.Component.setSize(Component.java:1770) at demos.jrefract.JRefract.run(JRefract.java:84) at demos.jrefract.JRefract.main(JRefract.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.javaws.Launcher.executeApplication(Unknown Source) at com.sun.javaws.Launcher.executeMainClass(Unknown Source) at com.sun.javaws.Launcher.continueLaunch(Unknown Source) at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source) at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source) at com.sun.javaws.Launcher.run(Unknown Source) at java.lang.Thread.run(Thread.java:595)

The program runs on my ATI Radeon 9800 Pro with the 4.9 Catalyst drivers. I had problems a while back with 4.10 and haven't tried upgrading since, though I'll try to at some point. On this configuration I can reproduce the memory leak. It is ATI-specific; the program runs fine on my NVidia-based laptop. I'm not sure there is anything we can do in JOGL to work around this, but I've filed Issue 137 to track it. I would recommend you file a bug on ATI's web site and point them at that test case.

This is a good question. The conventional wisdom is that certain programmers want the ability to optimize their rendering loops to make the OpenGL context current once and leave it current forever. JOGL supports this optimization where possible via the setRenderingThread API, which is disabled when the single-threaded workaround is enabled. However in my recent tests I have found that the performance difference between the optimized context handling with setRenderingThread and the single-threaded workaround is very slight or even unmeasurable, even for performance-sensitive tests like the VertexArrayRange demo. I don't think we'll switch the default to using the single-threaded workaround, but in whatever documentation gets written up in the future we'll probably recommend enabling the single-threaded workaround for best compatibility.

I am not sure whether this is the right place for bug reports, but anyway, it seems that with this version texture loading/mipmap generation does no longer work for textures with sizes that are non power-of-two. (It did work with the previous version.)

You can use the switch "-Djogl.glu.nojava" to use the old working code. What pixel type are you using? There is a know bug when using packed pixels, the non-packed routines should work.

Thanks, the switch does work. I have an image of size 756 X 512 (TYPE_3BYTE_BGR) that I try to load with : glu.gluBuild2DMipmaps(GL.GL_TEXTURE_2D, GL.GL_RGB,bufferedImage.getWidth(), bufferedImage.getHeight(),GL.GL_BGR, GL.GL_UNSIGNED_BYTE, textureBuffer ); This causes a java.nio.BufferUnderflowException, at net.java.games.jogl.impl.mipmap.ScaleInternal.scale_internal_ubyte(ScaleInternal.java:222)But when I resize the texture to 512 X 512, everything works fine.

I ran my app on 1.1b08 and it STILL crashes....I was hoping this ATI fix would be stable by now, but it still crashes. Here's the info:Powerbook G4 Mac OS 10.3.8ATI Radeon 9600 XT

Have you tried specifying -DJOGL_SINGLE_THREADED_WORKAROUND=true manually on the command line? Can you post the HotSpot error log or exception backtrace? I don't have a Mac with an ATI card to test with, but your app runs fine on my Windows box, though you should probably provide a batch file to set the system property -Dsun.java2d.noddraw=true or set that system property at the beginning of your program before creating any windows. BTW, you are distributing JOGL 1.1 b03 with your Windows download...

I have an image of size 756 X 512 (TYPE_3BYTE_BGR) that I try to load with : glu.gluBuild2DMipmaps(GL.GL_TEXTURE_2D, GL.GL_RGB,bufferedImage.getWidth(), bufferedImage.getHeight(),GL.GL_BGR, GL.GL_UNSIGNED_BYTE, textureBuffer ); This causes a java.nio.BufferUnderflowException, at net.java.games.jogl.impl.mipmap.ScaleInternal.scale_internal_ubyte(ScaleInternal.java:222)But when I resize the texture to 512 X 512, everything works fine.

Do you have a test program that shows the bug? Could you please file a bug with the Issue Tracker on the JOGL home page and add your test case as an attachment? Thanks.

But the same api works well when I use the GLCanvas. The problem is I need the Panel, because I use swing and a mix of light and heavy weighted components is terrible. The canvas is always in the foreground and no menu or tooltip can be seen.

With this release the api starts but when I click in the panel to rotate, it will be aborted again.

What OS and graphics card are you using? Are you using your vendor's most recent set of drivers? Do you have a test case which shows this crash? If so, could you please file a bug with the Issue Tracker on the JOGL web page and add your test case as an attachment?

Quote

The problem is I need the Panel, because I use swing and a mix of light and heavy weighted components is terrible. The canvas is always in the foreground and no menu or tooltip can be seen.

If your only problem is menus and tooltips, I think calling JPopupMenu.setDefaultLightWeightPopupEnabled(false) should put those in heavyweight containers. See the JOGL User's Guide.

xception in thread "X3d[myUniverse]" net.java.games.jogl.GLException: Error making context current at net.java.games.jogl.impl.x11.X11GLContext.makeCurrent(X11GLContext.java:154) at net.java.games.jogl.impl.x11.X11OnscreenGLContext.makeCurrent(X11OnscreenGLContext.java:111) at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:203) at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:186) at net.java.games.jogl.GLCanvas.display(GLCanvas.java:74) at com.xith3d.render.jogl.CanvasPeerImpl.render(CanvasPeerImpl.java:1162) at com.xith3d.scenegraph.View.renderOnce(View.java:592) at ext.xith3d.base.XithWorld.updatePostwork(XithWorld.java:210) at kernel.math.geom3dv2.World3d.update(World3d.java:220)

OS: Suse 9.1 Graca: Ti4600: Driver 55xx, and 6629

I had the same problem some time ago while using the nvidia 44?? driver. Updating the driver resolved the issue back then.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org