On 19/06/2012 9:54 PM, Mark Callow wrote:
We actually didn't deliberately enable centroid sampling. The problem is that point sprites require gl_PointCoord to range from 0.0 to 1.0 in each dimension across the sprite, and every other varying has to have the same value for each fragment, as the value from the vertex output. The latter is achieved by using the "COLOR" semantic in Direct3D 9's HLSL code, while gl_PointCoord is implemented as a built-in varying using the "TEXCOORD" semantic which for point sprites makes it vary from 0.0 to 1.0. So far so good, but COLOR actually enables centroid sampling on devices that support it (while with TEXCOORD it's optional).
I don't think centroid sampling is of any particular value to ANGLE. It appears to be causing more harm than good, even though it's fully within spec and there appears to be consensus that the 1.0.2 conformance tests will have to be fixed. But it leaves the issue of artifacts that pop up only with ANGLE, that are not easily identified as being caused by anti-aliasing technology. Also, disabling anti-aliasing isn't always a desirable solution. For instance I believe Google Maps renders text that suffers from centroid sampling artifacts, but can use anti-aliasing for the visual quality elsewhere.
So I'm starting to lean toward doing what is necessary to disable centroid sampling, despite being spec compliant. It means point sprites will have to be implemented very differently though. It might be possible using instancing, but it won't be straightforward.
Anyhow, thanks for your input! I think the rest of it will be an ANGLE-specific discussion. Unless anyone else has strong feelings about (not) getting rid of centroid sampling...