gl_FrontFacing broken in some circumstances

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Check out the three.js repository from https://github.com/mrdoob/three.js/
2. Replace examples/webgl_loader_obj.html with the attached version.
3. Run 'python -m SimpleHTTPServer' and navigate Chrome Beta or later under 
localhost:8000/examples/
4. Click and drag to rotate the model.

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

The demo computes the color of the object using gl_FrontFacing. The expected 
output is solid white. Under some viewing angles, ANGLE is computing the 
gl_FrontFacing variable incorrectly, and the model shows up solid black. 
Interestingly, the bug happens for the entire model, not just a single triangle 
or pixel.

This seems to be a regression in Chrome 29. Please investigate quickly so that 
the impact is understood.

Original issue reported on code.google.com by kbr@chromium.org on 7 Aug 2013 at 3:30

Attachments:

• webgl_loader_obj.html

[GoogleCodeExporter]

Original comment by shannonw...@chromium.org on 8 Aug 2013 at 3:31

[GoogleCodeExporter]

The behavior I'm currently seeing is that the entire canvas renders white-- I 
can see no model, and white text disappears/blends in to the canvas once 
rendering begins. This behavior occurs with:

Chrome Stable with built-in DLLs
Chrome Canary with built-in DLLs
Chrome Canary with current ANGLE master branch HEAD, DX11 not enabled
Chrome Canary with current ANGLE master branch HEAD, DX11 enabled
Chrome Canary with ANGLE legacy branch HEAD
Any of the above with --use-gl=desktop

I also can't pull up the right-click contextual menu. Not sure what's going on 
here.

Original comment by shannonw...@chromium.org on 8 Aug 2013 at 8:56

[GoogleCodeExporter]

On my Windows workstation (Z620, NVIDIA Quadro 600, 310.90 drivers), with 
Chrome 30.0.1594.2 (Official Build 216911) canary, the model initially loads 
black. Left-clicking and dragging around the window causes the model to 
occasionally turn the (correct) white. It looks like when viewed from the top, 
the model renders correctly, but when viewed from below, it often renders 
incorrectly. Clicking and dragging from the bottom of the window to the top 
might cause the problem to occur more readily.

Original comment by kbr@chromium.org on 12 Aug 2013 at 6:22

[GoogleCodeExporter]

Also, the problem doesn't happen with Chrome 28.0.1500.95 (Official Build 
213514) m on the same hardware.

Original comment by kbr@chromium.org on 12 Aug 2013 at 6:23

[GoogleCodeExporter]

I'm able to reproduce this now and have tracked it down to r0b236e2ec3 -- it 
will affect the master and es3proto branches only, not legacy.

It appears that we used to do the calculation of FrontFacing anew whenever 
setViewport was called, and there was a shader program currently set, but as of 
that commit, it only gets recalculated if the viewport has changed. 

Geoff, the change was one you made to address a bug which I'm not familiar 
with. Would you mind taking a look to see how we can handle this correctly 
without reintroducing the prior bug?

Original comment by shannonw...@google.com on 14 Aug 2013 at 1:04

[GoogleCodeExporter]

Figured out what the issue was; the gl_FrontFacing constant would not be 
updated in some cases when glFrontFace changes in the middle of a frame.

Fix will land soon.

Original comment by geofflang@chromium.org on 14 Aug 2013 at 4:37

[GoogleCodeExporter]

Original comment by shannonw...@chromium.org on 14 Aug 2013 at 4:47

• Changed state: Review

[GoogleCodeExporter]

Landed at rd03104370d93

Original comment by shannonw...@google.com on 14 Aug 2013 at 7:38

• Changed state: Fixed

[GoogleCodeExporter]

Can we lobby for backporting this fix to Chrome 30? Is it feasible?

Original comment by kbr@chromium.org on 15 Aug 2013 at 1:27

[GoogleCodeExporter]

Probably? I haven't done any of the Chrome-side deps and branch management.

Original comment by shannonw...@google.com on 15 Aug 2013 at 3:17

[GoogleCodeExporter]

Al, could you please help get this change merged back?

Original comment by kbr@chromium.org on 15 Aug 2013 at 5:02