oizma / angleproject

Automatically exported from code.google.com/p/angleproject
Other
0 stars 0 forks source link

glClear does not work correctly #34

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Run the WebGL glClear conformance test using ANGLE

What is the expected output? What do you see instead?

The test should pass. It doesn't.  It does pass in OpenGL

Note, this is a semi follow up to this issue
http://code.google.com/p/angleproject/issues/detail?id=31

This is the cause of why some of the demos are brighter in ANGLE than in 
OpenGL. At the end of the frame of nearly all the demos I do this

    // Set the alpha to 255.
    gl.colorMask(false, false, false, true);
    gl.clearColor(0,0,0,1);
    gl.clear(gl.COLOR_BUFFER_BIT);

But based on certain state which so far I haven't been able to figure out ANGLE 
doesn't clear to 255. I've stepped through their code in the debugger and I see 
that when colorMask is not (true,true,true,true) ANGLE draws a quad with the 
D3D Fixed Function Pipeline instead of calling Clear(). I can't tell why it's 
not clearing correctly though.

I've run ANGLE in PIX and I see where the clear happens. I see the vertices 
have the correct color and I also see what PIX calls the pixel shader is 
producing the bad color (even though there isn't a pixel shader. Then again, 
maybe there is internally)

In the aquarium it ends up clearing to 147 which means the entire scene gets 
composited with the canvas background color which is grey. If you set the 
canvas's background color to RED then you really see the bug.

To verify I added these 3 lines to the demo

    var buf = new Uint8Array(4);
    gl.readPixels(0, 0, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, buf);
    tdl.log(buf[3]);

And it prints 147.

Anyway, I tried to write a gl.clear WebGL conformance test and found more bugs 
apparently. 
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conforma
nce/gl-clear.html

Here's the results of the test in OpenGL

Test clear.

On success, you will see a series of "PASS" messages, followed by "TEST 
COMPLETE".

PASS getError was expected value: NO_ERROR : Should be no errors from setup.
PASS should be 0,0,0,0
PASS should be 255,255,255,255
PASS should be 0,0,0,0
PASS should be 0,0,0,255
PASS should be 128,128,128,192
PASS should be 128,128,128,255

PASS successfullyParsed is true

TEST COMPLETE

And on ANGLE

Test clear.

On success, you will see a series of "PASS" messages, followed by "TEST 
COMPLETE".

PASS getError was expected value: NO_ERROR : Should be no errors from setup.
FAIL should be 0,0,0,0
expected: 0,0,0,0 was 0,0,0,128
PASS should be 255,255,255,255
PASS should be 0,0,0,0
FAIL should be 0,0,0,255
expected: 0,0,0,255 was 0,0,0,128
PASS should be 128,128,128,192
FAIL should be 128,128,128,255
expected: 128,128,128,255 was 128,128,128,192

PASS successfullyParsed is true

TEST COMPLETE

I notice that the initial alpha color is whatever was left over from the last 
call to clear in a previous program. That suggests something.

Original issue reported on code.google.com by g...@chromium.org on 16 Sep 2010 at 1:49

GoogleCodeExporter commented 9 years ago
It's caused by assuming that the fixed-function pixel pipeline is in the 
default state (copying the diffuse color to the output). However, the 
fixed-function pixel pipeline is also used for vertically flipping the color 
buffer at eglSwapBuffers.

Patch attached.

Original comment by Nicolas....@gmail.com on 16 Sep 2010 at 4:16

Attachments:

GoogleCodeExporter commented 9 years ago
This is committed in r426

Original comment by dan...@transgaming.com on 16 Sep 2010 at 8:25