627998 - Clothes are tigered in Google Bodybrowser using ANGLE

Status: VERIFIED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[Scoobidiver (away)]

Attachment: Screenshots of Bodybrowser in Fx 4 and Chrome 10

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110121 Firefox/4.0b10pre

Fx 4 and Chrome 10 use both ANGLE but the rendering is different.
The clothes are tigered in Fx4 and normal in Chrome (see attachment).
If I use Intel's OpenGL renderer, it is OK in Fx 4.

Adapter Description: Mobile Intel(R) 4 Series Express Chipset Family
Vendor ID: 8086
Device ID: 2a42
Adapter RAM: Unknown
Adapter Drivers: igdumd64 igd10umd64 igdumdx32 igd10umd32
Driver Version: 8.15.10.2226
Driver Date: 10-15-2010
Direct2D Enabled: true
DirectWrite Enabled: true (6.1.7600.20830)
WebGL Renderer: TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 21 2011 16:16:36)
GPU Accelerated Windows: 1/1 Direct3D 10

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Repro'd on WinXP with Mozilla/5.0 (Windows NT 5.1; rv:2.0b10pre) Gecko/20110121 Firefox/4.0b10pre ID:20110122065721 and

        Adapter Description       Radeon X1950 Pro
        Vendor ID                 1002
        Device ID                 7280
        Adapter RAM               Unknown
        Adapter Drivers           ati2dvag
        Driver Version            8.593.100.0
        Driver Date               2-10-2010
        Direct2D Enabled          false
        DirectWrite Enabled       false (0.0.0.0)
        WebGL Renderer            TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 20 2011 21:33:17)
        GPU Accelerated Windows   1/1 Direct3D 9

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Does this still happen?  It's likely a depth precision issue, where body browser expects that a 16-bit depth is actually higher precision internally -- which is the case with desktop GL, but not with ANGLE currently.  Benoit's working on a fix in bug 628382.

Comment 3

[Scoobidiver (away)]

> Does this still happen?
It still occurs in 4.0b10pre/20110124.

Comment 4

[Scoobidiver (away)]

After the fixing of bug 628382 in 4.0b11pre/20110126, it still happens.

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Ah, so the problem here is that the actual main depth buffer is being created as 16bpp.  I don't know why ANGLE is doing this; looking into it now.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: try to get a 24bpp depth buffer if possible

This builds on top of the patch in bug 628088, and does some cleanup that jeff asked for there.

It always attempts to get an 8-bit color/24-bpp depth buffer config and goes down to the minimums from there.  Fixes this issue here.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 508035 [details] [diff] [review]
try to get a 24bpp depth buffer if possible


>+static void
>+FillPBufferAttribs(nsTArray<EGLint>& aAttrs,
>+                   const ContextFormat& aFormat,
>+                   bool aCanBindToTexture,
>+                   int aColorBitsOverride,
>+                   int aDepthBitsOverride)
>+{
>+    aAttrs.Clear();
>+
>+#define A1(_x)      do { aAttrs.AppendElement(_x); } while (0)
>+#define A2(_x,_y)   do { A1(_x); A1(_y); } while (0)

This is sort of ugly, but perhaps unavoidable.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Yeah, it makes the code more readable.  At some point we should probably just make a little IntAttribList helper class and use it everywhere.

Comment 9

[Benoit Jacob [:bjacob] (mostly away)]

We should also talk to the authors of this demo to fix it (it shouldn't rely on 24bpp depth buffers for correct rendering). I guess that it can be fixed with just a call to webgl.polygonOffset().

Comment 10

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Yeah, I sent the note to Vangelis already; he'll look into it.  http://hg.mozilla.org/mozilla-central/rev/688dd0a52427

Comment 11

[Scoobidiver (away)]

Verified in 4.0b11pre/20110201.