1/4 pixel shift after fragment shaders

I’m having a problem that seems to have something to do with antialiasing.

I am adding some code of my own to an existing OpenGL application. Just before the application calls swapbuffers, I draw a quad on the screen and enable a fragment shader of my own that either outputs 100% blue or 100% white depending on the Y texture coordinate.

The result is a quad that is part blue near the top, part white near the bottom and has a 75% blue line in between.

By varying the Y coordinate in the shader at which to switch to white, I cannot get a 100% blue line followed by a 100% white line. There is always a 75% blue line in between.

What could be the cause of this?

The application uses ARB_multisample, but although SAMPLE_BUFFERS_ARB is 1, I disable MULTISAMPLE_ARB before I start drawing the quad.

This image shows the problem. In this case my shader is drawing the black and white bars. The left half is what it should be and the right part is what I get. It looks like a 1/4 pixel shift, but I can’t figure out what is causing it.

I have no concrete idea what is causing your problem. I just have a hint for you: on R300 based ATI cards, glDisable(GL_MULTISAMPLE_ARB) does nothing, multisampling stays enabled. I don´t know about the newer cards. Another problem might be related to the settings that influence the coverage value of the fragments…

You can’t just go disabling a property that’s inherently linked to your framebuffer once you start rendering and expect useful results.

w.r.t. the sample pattern, perhaps you have something like quincunx sample pattern making it tricky to intuitively get a sample sum result binary between two pixels.

Have you tried creating a framebuffer that doesn’t have Multisample at all and seeing if that fixes it? That’ll show if the issue is AA or in your shader.

It would also help to see the code in your shader and perhaps the code that draws the quad - that might show where the problem is.

quincunx I tell ya.