[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Weird alpha issue.
- To: "Mo, Zhenyao" <email@example.com>
- Subject: Re: [Public WebGL] Weird alpha issue.
- From: firstname.lastname@example.org
- Date: Mon, 1 Nov 2010 11:16:16 -0700
- Cc: "Steve Baker" <email@example.com>, "Benoit Jacob" <firstname.lastname@example.org>, "public webgl" <email@example.com>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=sjbaker.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:mime-version :content-type:content-transfer-encoding; s=sjbaker.org; bh=6W5uU tH7gNWckGCMZENFLzMhyko=; b=R8RuZ0dwC/pZSKYaCYAy4+ShVywEKTL/JTDLP IOoWM8/uPPTkSt9lnYIy+7iaDWvqDQE0xiu61FDASdX4sfsIVG1hR+RFAjqUcvXX H0y+E3n/pjJskFrTof49LdR5DVSrsNzJyNN4Pj4B/D8t84VjU1lv5IhhTy/enGgT f54tWE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=sjbaker.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:mime-version :content-type:content-transfer-encoding; q=dns; s=sjbaker.org; b=r9rCIYNsanCwDIu7xSw2el59YY0ag9sXFEMJSm+kcPH71LjZRSpBMwlxitoFq bY5ygDPp3fE80y5oOAleRhuXIANobXKFni9W8JzPzP3y99OEle4nuaNRUYlry9zT hcBCLew9+HD5/6rajWH4EGwVg3TH+btVhLfvTaqON5mHV4=
- In-reply-to: <AANLkTinKw2B8JedaHL=AdtptQT8OdDnu15yk+bZpzWYu@mail.gmail.com>
- References: <1891782920.235028.1288551072750.JavaMail.firstname.lastname@example.org> <4CCDD960.email@example.com> <AANLkTinKw2B8JedaHL=AdtptQT8OdDnu15yk+bZpzWYu@mail.gmail.com>
- Sender: firstname.lastname@example.org
- User-agent: SquirrelMail/1.4.21
Yep - it looks fine in the Canary build under Windows with --use-gl=desktop.
Presumably that's the difference though. Under Linux, Chrome is forced to
use OpenGL because it's the only game in town. If there is no
destination-alpha bug in Chrome/OpenGL then that explains what I'm seeing.
You're not seeing my problem with ANGLE right now because it's broken and
you don't see anything at all (neither do I since it auto-upgraded
sometime yesterday). The older Windows build I have been using (sorry - I
don't have the version number to hand right now) runs ANGLE OK - and there
the background-leakage bug is more or less the same as in Minefield...but
I don't think there is a common cause because Minefield under Linux uses
OpenGL and it's also broken.
I'd guess that ANGLE is ignoring "alpha:false" in getCompositor and
returning me a destination-alpha canvas come-what-may - but OpenGL is
doing the right thing.
> I tried your test case with top-of-tree Chrome on Mac and Windows.
> Both do not have the background leaking issue you saw here. Can you
> try the same build and confirm?
> For the Windows build, you need to pass in --use-gl=desktop flag.
> Apparently there is a bug in ANGLE, so without the flag you won't see
> the WebGL canvas at all - at least that's the case on my machine.
> On Sun, Oct 31, 2010 at 2:02 PM, Steve Baker <email@example.com> wrote:
>> OK - I finally have a reasonably simple test case at:
>> ...I apologize if some of the code doesn't look exactly pretty - it's
>> been brutally ripped out of a 5000 line application. The checkerboard
>> background helps you see the blending issues clearly - but it's a bit
>> hard on the eyes!
>> We should see a dark brown canvas on a checkerboard background - with a
>> chair and a grey translucent 'smoke puff' slicing through it.
>> * The only setup that I've found seems to display it "correctly" (ie
>> without dest-alpha) is Chrome under Linux/64bit...but I don't have a Mac
>> to test on so we'll give Safari the benefit of the doubt right now.
>> * Minefield lets the background 'leak' through the image (presumably
>> because we can't shut off destination-alpha because of bug 539771.
>> (That's a **REALLY** serious bug!)
>> * Chrome under Windows7/32bit also lets the background leak through -
>> but does a weird compositing job.
>> * None of the browsers are getting the alpha=0 thing right.
>> * If you remove the "alpha:false" from the getContext call - you can
>> also see that Chrome and Minefield composite the resulting dest-alpha
>> canvas differently.
>>> If you go to about:config and set
>>> Does that make a difference?
>> No...no difference at all.
>>> If yes, you have found a bug in our accelerated compositing code.
>>> If no, we can't conclude anything.
>> Oh. :-(
>> -- Steve
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: