GLJPanel "lagging" by one frame [when multisampling is on].

I am changing my code to use either a GLCanvas or a GLJPanel depending on which is more likely to work / not crash / on a given JVM, OS combination.

Probably the relevant detail is that I am not animating the canvas / panel, but I am repainting it whenever the model changes.

With the GLJPanel version everything seems to "lag" one frame behind. If the user modifies a thing from state A to B my display() method gets called and draws the B state but state A stays on screen. If the user then changes from B to C the display() is called and draws the C state, but at the end the B drawing from last time is shown... So the 3d is always one user interaction behind.

Additionally I am implementing picking with colors / drawing / glReadPixels. On a mouse click I draw in pick mode, read a pixel, then clear and draw in normal textured & colored mode. Don't make fun of me it is 5 lines of code, took 3 minutes to write, and is 1000x faster than it needs to me for my app.

Anyway, the pixel values I read back with glReadPixels are from the previous frame too!

Frankly I could render everything twice, but can anyone explain what's up? I can see the display thing because of the way the GLJPanel works, but I don't understand why that would mess with the read pixels call.

I haven't worked with those classes but it almost sounds like some double buffering going on. Display() draws to a buffer that then (isn't) blitted to the screen.
Maybe the status oF GLCanvas.getAutoSwapBufferMode() can give a hint?

Yes, it seems like some sort of double buffering, and given more time to think about it I realize that if my glReadPixels are getting the previous display()'s results, and so is the GLJPanel's code that glReadPixels the buffer then flips and blits it into the Buffered Image's raster, they could both be explained by drawing to a back buffer, but reading from the front buffer.

I'll look deeper into the code, I was on a bus all day yesterday working on it and did not realize that I was using 2.0.2-RELEASE, but had RC11 source code in my debugger, so that wasted a little time, GLJPanel did not make sense :-P

A few things narrowed down:

With jogl.gljpanel.noglsl set the GLJPanel lags one frame behind. Each call to display() renders frame N but blits frame N-1 to the buffered image, and then to the screen. The first call to display() displays garbage from video memory on screen. I am pretty sure GLJPanel.OffscreenBackend.postgl() is to blame, in the if statement where it chooses to use the glsl method to perform the image flip it calls fboDrawable.swapBuffers() but in the non-glsl branch it does no such thing.

Why was I disabling the GLSL method? Because if you are a madman who has left your winding mode the "wrong" way around the glsl method fails to draw. I assume that the geometry it uses to draw the texture to fboFlipped is culled away.

So:

Probable Bug 1: The glsl image flip relies on the winding mode being normal (CCW). Easy to workaround.
Possible Bug 2: The non-glsl branch does not swap buffers before reading pixels, so is one buffer behind.

But I am left pretty confused about why there is double buffering for the offscreen render.. and why I can't read pixels.

I finally put the last bit of the puzzle together: Both my own glReadPixels call, and the one in the no-glsl version, are having trouble because GLJPanel uses FBOs and I am using multisampling, and reading from a multisampled fbo is not a thing that is going to work right, apparently. Both problems go away if I turn off multisampling.

Anyway, I am going to make the GLJPanel the fallback mode for troublesome systems, like Java 7 and OSX, until GLCanvas gets more stable.

On 09/23/2013 03:51 AM, bkuker [via jogamp] wrote:
> I finally put the last bit of the puzzle together: Both my own glReadPixels
> call, and the one in the no-glsl version, are having trouble because GLJPanel
> uses FBOs and I am using multisampling, and reading from a multisampled fbo is
> not a thing that is going to work right, apparently. Both problems go away if
> I turn off multisampling.

https://jogamp.org/bugzilla/show_bug.cgi?id=841 ?

>
> Anyway, I am going to make the GLJPanel the fallback mode for troublesome
> systems, like Java 7 and OSX, until GLCanvas gets more stable.

So this is related to OSX/Java7 only ????

Please refine Bug 841 !!! Thank you!

~Sven

CONTENTS DELETED

I have just confirmed that the problem occurs with GLJPanel + jogl.gljpanel.noglsl + Multisampling, and happens on my windows 7 machine as well as OSX.

Test program attached to the bug report.

This is really minor, because at 60fps its a 13ms lag (might still bother the Quake crowd) and at on-demand 0.1 fps I just call display() before repaint() and render it twice, who cares.

Also I don't need to disable GLSL anymore :)

Mainly to help out anyone who stumbles upon this thread in the future, I will also mention that I entered https://jogamp.org/bugzilla/show_bug.cgi?id=842 for the bug I described regarding the FrontFace setting screwing with the GLSL flipper.

bkuker wrote

This is really minor, because at 60fps its a 13ms lag (might still bother the Quake crowd) and at on-demand 0.1 fps I just call display() before repaint() and render it twice, who cares.

Quake crowd doesn't use GLJPanel, GLWindow is far better for first person shooters :)