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

Gregg Tavares (wrk) [email protected]
Mon Sep 26 17:47:14 PDT 2011


I don't see how this test would have anything to do with anti-aliasing.

It just draws overlapping quads. It draws overlapping quads, all at the same
location, the only difference being the last quad is a green instead of
red.

All the test does is check the last quad gets drawn by checking for green

(in other words, if there was a bug that limited count to 65535 then the
last quad would not be drawn and you'd see red)





On Mon, Sep 26, 2011 at 4:38 PM, Jeff Gilbert <[email protected]> wrote:

>
> 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" <[email protected]>
> To: "Jeff Gilbert" <[email protected]>
> Cc: "public webgl" <[email protected]>
> 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 <[email protected]>
> 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 [email protected]
> > To unsubscribe, send an email to [email protected] with
> > the following command in the body of your email:
> > unsubscribe public_webgl
> > -----------------------------------------------------------
> >
> >
>
> -----------------------------------------------------------
> You are currently subscribed to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110926/0d0fe426/attachment.html>


More information about the public_webgl mailing list