[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Problem with 'more-than-65536-points.html' test



Yes, it's bleed-through from between the two tris, a line of faint reddish pixels along part of the seam. This is the only test which is regressing from without antialiasing.
There's clearly a problem somewhere, but it isn't a problem with the number of points: When I reduce the number of quads to only two (one red, then one green), the problem persists.

If we want to test for bleed-through with AA, we should absolutely do so, but (if possible) not in an unrelated test. I'm willing to write up a test if we want to add this.

I agree that it's odd that this is the only test where this is apparently a problem, however I would like to be sure that when this test fails, that it's not just because of antialiasing issues, and is instead because of improper handling of large numbers of points.

-Jeff

----- Original Message -----
From: "Kenneth Russell" <kbr@google.com>
To: "Jeff Gilbert" <jgilbert@mozilla.com>
Cc: "public webgl" <public_webgl@khronos.org>
Sent: Monday, September 26, 2011 4:12:24 PM
Subject: Re: [Public WebGL] Problem with 'more-than-65536-points.html' test

How exactly is the test failing? Are non-green pixels bleeding through
at the edges of the canvas, or is something else happening?

I don't think we've seen any failures of this test on any platform in
Chromium, where antialiasing support for WebGL has been present for
some time.

It's strange that only this test would be affected by the presence of
antialiasing. Are you sure that others aren't affected?

In principle it would be fine with me to disable antialiasing for this
test, but I feel that would probably be a hack which doesn't really
solve the problem.

-Ken

On Mon, Sep 26, 2011 at 3:04 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
>
> Hi,
>
> In implementing antialiasing for Firefox, I am getting failures on this test for some rendering paths, and only for some sampling levels.
> While it's possible that this is a driver bug (since this is only on our native GL path, and not with ANGLE), it doesn't seem to me that this test should be using antialiasing. A problem with antialiasing shouldn't fail it even though the issue it's supposed to be testing passes.
>
> Just disabling antialiasing in this test would keep this test specific. If we want to test for the antialiasing artifacts that are causing this test to fail, I think we should make that a separate test.
>
>
> -Jeff
>
> -----------------------------------------------------------
> 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
> -----------------------------------------------------------
>
>

-----------------------------------------------------------
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
-----------------------------------------------------------