GLJPanel in Lion

Hey,

We're using JOGL heavily integrated into a Swing app and it seems that the upgrade to Lion has caused glitchy behavior in GLJPanel, although GLCanvas is working fine.

Here're the screencaps.

This is GLCanvas and it's doing the right thing:


This is GLJPanel:


Here only a narrow strip of the graph is showing.  Additionally, mouse events seem to happen upside down to the small piece of the graph I can see.

The interesting thing is that the white selection box shown is using the same mouse events and drawing with traditional client-side GL_QUADS.  The nodes themselves are point sprites being drawn with a VBO and colored/blended via frag shader.

The error also seems to be exclusive to the newer AMD MacBook Pro model (I've tried it on the top-end one and the mid-range one).  The last generation NVIDIA-based ones seem to work fine.

Any thoughts?  I tried upgrading to the latest dev builds/native libs but the same problem happens there.  Things are fine on Windows (although GLJPanel is WAY slower).

Thanks,
Ryan


Just in case, here's the code where I initialize either the panel or the canvas:

                GLCapabilities capabilities = new GLCapabilities(profile);
               
                renderer = new JOGLViewerRenderer();
                handler = new JOGLInputHandler();
                if (canvasType == CanvasType.CANVAS) {
                        glCanvas = new GLCanvas(capabilities);
                        glCanvas.addGLEventListener(renderer);
                        glCanvas.addKeyListener(handler);
                        glCanvas.addMouseListener(handler);
                        glCanvas.addMouseMotionListener(handler);
                        glCanvas.addMouseWheelListener(handler);
                        canvas = glCanvas;
                } else {
                        glPanel = new GLJPanel(capabilities);
                        glPanel.addGLEventListener(renderer);
                        glPanel.addKeyListener(handler);
                        glPanel.addMouseListener(handler);
                        glPanel.addMouseMotionListener(handler);
                        glPanel.addMouseWheelListener(handler);
                        canvas = glPanel;
                }

So you're saying that GLJPanel worked fine on an AMD MacBook Pro under Snow Leopard, but when you upgraded that same computer to Lion, GLJPanel started showing problems?

It's interesting that the ring-thingy seems to be reflected about the x axis in the bottom screen shot (assuming the two screen shots are supposed to look roughly the same). I know the GLJPanel supposedly does some software compositing to get more correct results -- maybe the composited bitmap is somehow flipped under Lion?

You might try defining jogl.gljpanel.nohw, jogl.gljpanel.noogl, or jogl.gljpanel.nosw with -D on your Java command line to see if they make any difference. They enable/disable the different possible backends for GLJPanel, and might give us a hint as to what's going on. You can see in the code at https://github.com/sgothel/jogl/blob/master/src/jogl/classes/javax/media/opengl/awt/GLJPanel.java what those properties do.

Exactly.  The GLJPanel looks/acts exactly like the GLCanvas on Snow Leopard but has the symptoms in the screenshot on the exact same machine (a new AMD-flavored MBP).  It also happened on a different MBP (with the slower AMD GPU on the new Macs) when it was upgraded to Lion.  I can confirm that the NVIDIA card in last years midrange MBP works fine on Lion.

Yeah, you're right about the reflection.  It even happens when you drag the nodes (they follow the mouse left and right but move in the opposite direction in their y coord).

I just tried each of those options (almost all permutations of all three) with absolutely no change visually or interactively (still inverted Y, still draw the GL_QUAD selection box just fine).

You might also try setting jogl.debug.GLJPanel and jogl.verbose, so you can see in the log which of the backends is being used (J2DOGLBackend, PbufferBackend, or SoftwareBackend). It seems unlikely that all three of those could be broken in the same way. At least, you should see a much slower frame rate when the software backend is in use

-Djogl.debug.GLJPanel -Djogl.verbose -Djogl.gljpanel.nohw -Djogl.gljpanel.noogl

And with just the verbose/debug flags the output is (on the integrated card):

JOGL specification version 2.0
JOGL implementation version 2.0-b426-20110812
JOGL implementation vendor JogAmp Community
GLJPanel.addNotify()
GLJPanel.handleReshape: (w,h) = (1000,578)
Resizing pbuffer from (256, 256)  to fit (1000, 578)
New pbuffer size is (1024, 1024)

Hmm, not sure what else to try. There are some vendor-specific code paths in the GLJPanel code, but those would be the same in Lion as they were in Snow Leopard. No warning or error messages show up in the log, which is good.

The fact that GL_QUADs work normally, while the fragment-shaded points don't, makes me a bit suspicious that it's a GL bug introduced with Lion (since Lion did upgrade their OGL level to 3.2). If there was really something wrong with GLJPanel's compositing, I'd expect everything to be flipped, not just the points.

If it were me, I'd probably try rendering more different types of objects in the GLJPanel to see if there's some pattern to what's flipped and by how much -- that might give some clue as to what's happening here. You could also compile JOGL (it's surprisingly easy, directions on wiki at http://jogamp.org/wiki/index.php/How_to_Contribute) and trace through GLJPanel a bit to see what's going on. That code's got a lot of warts on it due to workarounds for various driver bugs, so it may be going through an odd path that doesn't make sense on Lion.

My Occam's Razor was a shader bug on my end (due to the good GL_QUAD), but the counterevidence for that is that it works completely fine in GLCanvas (even on AMD hardware).  Is there any way to reconcile that?

Barring any other insights I guess I'll try and learn me some GLJPanel...

GLCanvas and GLJPanel do use different OGL features, so it's possible that if there were a driver bug GLJPanel would hit it and GLCanvas would not. But for a problem like this, nothing beats stepping through the code in the debugger to see what's really happening

I seem to have narrowed it down, but I don't know how to fix it.

The issue seems to be a shader bug.  Specifically, the y component of gl_FragCoord is different (and inverted or wrong or something) on the GLJPanel vs the GLCanvas.

Here's a minimal test case:

vertex shader:
#version 120

uniform vec2 screenSize;

void main(void)
{
        gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}

frag shader:
#version 120

uniform vec2 screenSize;

void main(void)
{
        vec4 testcolor = vec4(0.0, 0.0, 0.0, 1.0);
       
        if (gl_FragCoord.x > screenSize.x/2.0) testcolor.x += 0.5;
        if (gl_FragCoord.y > screenSize.y/2.0) testcolor.z += 0.5;

        gl_FragColor = testcolor;
}

screenSize is just a uniform that's set every draw call.

Here's what I'd expect this shader to draw (and this is what it draws with GLCanvas):



Here's what the exact same code in the GLJPanel does:



From fiddling with the second if statement I've figured out that at the top of the frame (which is 578px tall here) gl_FragCoord.y is about 450, and grows downwards (so the vertical middle is ~739).  Thus, a shader like this:

        if (gl_FragCoord.x > screenSize.x/2.0) testcolor.x += 0.5;
        if (gl_FragCoord.y > 739) testcolor.z += 0.5;

Produces this:



Any ideas on where to go next?  This happens on both software and hardware mode on both intel and amd cards.

You might print out the contents of the model view projection matrix that's visible inside the shader, to see if it's different in the GLCanvas and GLJPanel cases (and to see if it differs from the matrix you used for the GL_QUADs). If the matrix shows up different in the shader, it could be a driver bug is scrambling the matrix contents somehow. That might explain how GL_QUADs could look correct, but the shader could be wrong.

Alternately, GLJPanel could somehow be changing the matrix between when you draw your GL_QUADs and when you invoke the shader. You could put breakpoints in GLJPanel.java to see if that's happening (you'd have to build JOGL to do that, though, since the default JOGL build doesn't contain debug information).

I'll try this when I get back to a computer, but shouldn't gl_FragCoord be in screen coordinates anyway, making the mv matrix irrelevant?

On Aug 14, 2011 2:07 PM, "Wade Walker [via jogamp]" <[hidden email]> wrote:
>
> You might print out the contents of the model view projection matrix that's visible inside the shader, to see if it's different in the GLCanvas and GLJPanel cases (and to see if it differs from the matrix you used for the GL_QUADs). If the matrix shows up different in the shader, it could be a driver bug is scrambling the matrix contents somehow. That might explain how GL_QUADs could look correct, but the shader could be wrong.
>
> Alternately, GLJPanel could somehow be changing the matrix between when you draw your GL_QUADs and when you invoke the shader. You could put breakpoints in GLJPanel.java to see if that's happening (you'd have to build JOGL to do that, though, since the default JOGL build doesn't contain debug information).
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://forum.jogamp.org/GLJPanel-in-Lion-tp3250682p3254015.html
> To unsubscribe from GLJPanel in Lion, click here.

I didn't think of that... if it's always in screen coordinates, I can't think how those would get messed up except by a GL driver problem. Perhaps since GLJPanel does offscreen rendering, a GL driver bug could flip the coordinates available to the shader for that case, but not for the direct rendering case.

The fact that the colors are incorrect seems to rule out a simple flipping of GLJPanel's offscreen rendering when it copies to the main buffer (which was my first thought).

Well... I looked around GLJPanel a lot and couldn't figure out what the damn problem was.  All I know is that it happens regardless of the actual backend you're using.  It also happens in completely virgin code (the OneTriangle test from the JOGL guide).

My solution is kind of a hack, but it works well enough for now.  What I did was to (under Lion on non-nvidia cards) programmatically invert the distortion that was happening to the y coord of gl_FragCoord.  This can be done in the frag shader via:

float fixY(float badY) {
        return nextPowTwo-badY;
}

Where nextPowTwo is the smallest power of two that is larger than the current height.

I hope somebody else can find a better solution!

I think yours is a good solution for now -- we can wait and see if this bug goes away when they update the video drivers.