gl_FragColor multiplied against gl_Color for no reason

I’m trying get my GLSL shader working, but I have a really funky error I don’t think I’ve ever seen. This may be a JOGL bug, but I assume it’s a user error somehow.

My Java code…

   println(gl.glIsEnabled(GL.GL_BLEND)) // returns false so no blending
   shader.bind(gl)
   gl.glColor3f(1f,0f,0f)
   gl.glColor3f(0,0,0)
   gl.glBegin(GL.GL_QUADS)
   ...
   gl.glEnd()
   shader.release()

vertex shader…

void main() { 
    // Vertex transformation
    gl_Position = ftransform();
}

fragment shader…

void main() {
   gl_FragColor = vec4(0.8, 0.2, 0.2, 1.0);
}

I know the vertex shader is working because I can alter it’s final output location changing on my screen. With the fragment shader, something funky is going on.

I would expect with no blending to get a red on my screen, but what I get actually depends on glColor3f. If I put in glColor3f(0,0,0), I get black as if I have no shader. If I put in glColor3f(1,1,1), I get the color (.8,.2,.2) from my shader. I can adjust the values of glColor3f to adjust the output color, so it appears to my that glColor3f color is being multiplied by the final color in GLSL. To my knowledge, only blending would create a color different that the color from the gl_FragColor, but blending isn’t enabled.

Am I crazy? Is there a bug in my code? Could it be a JOGL issue?

This is a duplicate of this thread, but I wanted to present it on this forum just in case it was indeed a JOGL issue.

This seems very strange, however I can’t see how this is a JOGL bug. All JOGL does is pass calls down the line to the driver, so the shader code won’t be modified in any way. Also, it wouldn’t be blending that would cause these problems, since blending combines the incoming color with the color already stored at the pixel. Have you tried setting the glColor3f() to 1/2’s to see if the color value is halved? Otherwise I’d make sure that there’s no error being reported by OpenGL while rendering or from compiling the shader.