[Public WebGL] Centroid sampling makes conformance tests fail?

[Nicolas Capens <nicolas@transgaming.com>]

Hi all,

I'm a contributor to the ANGLE project, which implements OpenGL ES 2.0 
on Windows using Direct3D 9, and is used by Chrome and Firefox for 
implementing WebGL. Me and others have recently run into some issues 
which turn out to be caused by centroid sampling. But it doesn't appear 
that ANGLE is strictly speaking at fault, so I'm looking for some input 
on how to best deal with the issues...

The first one is that ANGLE "fails" to pass the WebGL conformance test 
for OES_standard_derivatives, on some hardware: 
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/extensions/oes-standard-derivatives.html.  
Although the resulting images are very dark, there is actually a 
different output along the diagonal. This is due to anti-aliasing being 
on (which is the default for WebGL), and Direct3D 9 can use centroid 
sampling in this case, which also affects the derivatives (which compute 
the difference in varying value between neighboring pixels). The second 
issue is closely related: 
http://code.google.com/p/angleproject/issues/detail?id=340. Because 
centroid sampling moves the location where the pixel is evaluated, and 
then applies the result to all covered samples, some places may appear 
to have shifted texels. And because the derivatives are also used to 
determine the mipmap LOD level, centroid sampling may affect that as well.

Using centroid sampling appears to be entirely within spec. The OpenGL 
ES 2.0 specification section 4.3.5 on varyings states that: "If 
single-sampling, the interpolated value is for the fragment center. If 
multi-sampling, the interpolated value can be anywhere within the pixel, 
including the fragment center or one of the fragment samples." Also, the 
OES_standard_derivatives extension suggests, but does not require, that 
"Functions should be evaluated within the interior of a primitive 
(interpolated, not extrapolated)."

This means that when anti-aliasing is enabled, there is a lot of leeway 
in what the result can look like! Hence I believe that the majority of 
the WebGL conformance tests should not be using anti-aliasing, unless 
that's explicitly part of the test. The alternative would be to not test 
values near the edges of polygons, although that seems quite haphazard 
and there's still no guarantee that all anti-aliasing implementations 
will evaluate the pixel at the center even when nowhere near an edge 
(think of quincunx anti-aliasing for instance).

It seems rather unfortunate to me that WebGL defaults to enabling 
anti-aliasing, given how much it can make the result differ between 
fully compliant implementations. Also, while it's possible to prevent 
ANGLE from using centroid sampling, it's not an easy thing to do, and 
there are actually cases where centroid sampling is valuable (which is 
why it exists in the first place).

So I'd like to know what other people's take on this is. Is it correct 
that the conformance tests make wrong assumptions and ANGLE is 
compliant? Or should we do whatever is necessary to prevent ANGLE from 
using centroid sampling? How can the issue of getting unexpected results 
because anti-aliasing is on by default be dealt with?

Thank you for your input!

Kind regards,
Nicolas Capens

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------