JOGL and Vista x64

OpenGL Development JOGL Development
#1

Is JOGL supposed to work with Vista x64 yet? I just tried last nights build and I still can’t get it to work. It works fine if I run it as a 32 bit app, but I need to get it to work as a 64 bit app. I am using 64 bit Java et al. It doesn’t crash but doesn’t seem to do anything either. The panel isn’t even black, it doesn’t get updated at all. Thanks.

By the way, I only find this problem with GLJPanel, it works with GLCanvas. I’m using Swing though. I guess I can just go back to GLCanvas, there were some issues but I was able to work around them.

#2

Sorry, we haven’t tested JOGL on 64-bit Vista. If you use the jstack tool in JDK 6 to gather a thread dump when the process appears to be doing nothing, we can at least see if there’s anything obviously wrong.

#3

I’ll look into getting the thread dump.

I didn’t notice until now, but this error pops up when running 64 bit. The problem is that it can’t create the offscreen map:

Exception in thread “AWT-EventQueue-0” javax.media.opengl.GLException: Error cre
ating offscreen bitmap of width 382, height 510
at com.sun.opengl.impl.windows.WindowsOffscreenGLDrawable.create(Windows
OffscreenGLDrawable.java:108)
at com.sun.opengl.impl.windows.WindowsOffscreenGLDrawable.setSize(Window
sOffscreenGLDrawable.java:67)
at javax.media.opengl.GLJPanel.initialize(GLJPanel.java:940)

It has something to do with the accumulation buffer. I find that if I remove the following lines, the panel does come up. It has some clipping problems but it’s mostly there. I had to put in spaces so that 8’s don’t show up as smileys.

    caps.setAccumAlphaBits(8 );
    caps.setAccumBlueBits(8 );
    caps.setAccumGreenBits(8 );
    caps.setAccumRedBits(8 );
#4

This sounds like an OpenGL driver problem. It looks like there’s no pbuffer support on Vista in your graphics drivers so you’re falling back to the Microsoft GDI software OpenGL implementation which is hopelessly obsolete.

#5

Ken, thanks for the tip about the driver. I was running the latest one from the computer manufacturer, but the chip maker had a newer version. It didn’t fix the pbuffer problem, but it did fix the clipping problem. I can live without the accum buffer for now.

I’m still trying to work around this. I tried calling GLDrawableFactory.getFactory().canCreateGLPbuffer() and it returns true. Is there another way to check if pbuffers are supported. I’m trying to write code that will detect if it’s supported and do the appropriate thing. I guess I could just trap the exception and swap out the GLJPanel with a new one.

#6

Sorry for the fact that this failure isn’t easy to detect.

You could try creating a 1x1 test pbuffer in your app and see if that succeeds or fails, to get an indication of whether pbuffer support is present. I don’t know exactly what you’re working around at this point (the lack of the accumulation buffer?) but that would probably tell you whether you can request those bits during the GLJPanel construction.

#7

Hey Ken. Thanks for the tip. I’m trying to set up my code so that if the pbuffers do allocate, that it use them. Otherwise just run without. That way I don’t have to have different version or configurations. I tried trapping the error when it happens and then replacing that GLJPanel with one without the accumulation bits set, but the new GLJPanel would generate the exception as well.

#8

I think the tip above should allow you to detect this. Post if you’re still running into problems.

#9

Ken. Definitely a driver problem. I tried on another machine running x64 and it works fine. So it’s just a bad driver.