Unable to reproduce the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.11.4 using chrome version 50.0.2661.87.Not observed any orange strips on middle car.
Please find the attached screen cast and confirm anything missed here in triaging.

Request you once please try the issue on new profile without any extensions and update if the issue still persists.

Thanks, 

@kavvaru Hmmm, I don't see here any attached screencast.

I did re-check without any extensions and the depth-precision artefacts are still there.

One thing to verify: make sure you do test with OpenGL rendering backend (which gets enabled by running Chrome with these command line flags "--use-angle=gl --disable-gpu-sandbox"), not with the default D3D11 ANGLE backend.

If you visit this page:

http://alteredqualia.com/tools/webgl-features/

Check there "Unmasked renderer" item. It should look something like this when OpenGL is used:

ANGLE (NVIDIA Corporation Quadro 2000M/PCIe/SSE2 OpenGL 4.5 compatibility)

But not like this:

ANGLE (NVIDIA Quadro 2000M Direct3D11 vs_5_0 ps_5_0)

-------------

Another thing coming to mind - it could be GPU vendor / driver specific. Both notebooks I observed this on have Nvidia GPUs (with the latest drivers - 364.72).

Are you on Chrome WebGL team? If I remember well some folks there have workstations with Quadros, so should be close to my HW config.

-------------

Anyways, not being able to reproduce it in Linux and OSX is a good news. This regress then may be localized to Windows OpenGL backend (where it's just an alternative), as opposed to all OpenGL backends, on platforms where OpenGL is the only option (OSX, Linux, Android).

Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

geofflang@ is the architect of ANGLE's OpenGL backend. Geoff, could you take a look?

Already assigned to an owner, hence no further triaging required.

FYI, I can still reproduce this. I suspect that ANGLE's treating the DEPTH_COMPONENT16 renderbuffer format literally. Chrome's WebGL implementation on top of OpenGL (without ANGLE) has historically promoted that format to a 24-bit depth buffer internally. 16 bits of depth precision is probably not enough for this demo.

The obvious workaround is to just allocate a DEPTH_STENCIL renderbuffer. No significant amount of memory's being saved by allocating a depth-only renderbuffer.

So I guess this means:

- ANGLE (DX11 code-path) internally promotes DEPTH_COMPONENT16 to 24-bits
- ANGLE (OpenGL code-path) keeps DEPTH_COMPONENT16 at 16-bit
- older native OpenGL code-path on Windows also used to also promote DEPTH_COMPONENT16 to 24-bit (and seems on Linux / OSX it may still do it?)

For what it's worth - WebGL introspection reports DEPTH_BITS as 24 (and STENCIL_BITS as 8).

http://alteredqualia.com/tools/webgl-features/

So if I understood well, then the only way how to get those 24 depth bits guaranteed in WebGL1 is to use combined depth+stencil format - DEPTH_STENCIL (which in WebGL2 is DEPTH24_STENCIL8)?

Sorry that this fell off my radar.

Your analysis is correct, I think you should be prepared to have 16-bit depth when you request DEPTH_COMPONENT16, DEPTH24_STENCIL8 is the only way to guarantee have 24 or more bits in WebGL1.

I guess I should close this unless we want to have ANGLE's GL backend mirror the other platforms.

From the WebGL content creator point of view - 16-bit depth is definitely not enough (not just in this particular example, I've noticed issues also in other places). So I commend you for fixing this shortcoming of WebGL1 / ES2 specs on the implementation side :).

It would be nice if ANGLE GL could also use 24-bit depth. I'm aware it's not guaranteed, but it's still better than using 32-bit depth+stencil format everywhere and just let 1/4 of memory being wasted for nothing.

BTW in WebGL1 there doesn't exist DEPTH24_STENCIL8 format. This one is only available in WebGL2. WebGL1 only has DEPTH_STENCIL, with uncontrollable precision from the API side (though I assume internally DEPTH24_STENCIL8 is always used?).

Ok, I hadn't realized that the getting the 24-bit depth is only available though an unsized format.  I'll look into increasing the bits on the DEPTH_COMPONENT16.

As an aside, you likely wont be saving any memory by expecting that the DEPTH_COMPONENT24 format is only 24 bits, it would be padded in the GPU memory.  D3D11 also doesn't have a 24-bit depth format without the stencil bits.