[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Weird alpha issue.
No problem! You'd be amazed at how lazy I am about keeping my website
tidy! It's a fairly safe bet that it'll still be there many years from
I'm just amazed at how such a seemingly tiny problem (my particle systems
look a bit darker in one browser than the other) has ballooned out into so
many different bugs!
* My own code was (originally) letting getContext default to destination
alpha when I didn't want it.
* Chrome gives me destination alpha all the time under ANGLE.
* Minefield gives me destination alpha all the time (this is a known bug).
* Chrome and Minefield disagree about how dest-alpha should be blended
into the underlying image. (Although I'm still not sure which one has the
bug)...which was the ultimate cause of my particle system problems.
* Both browsers incorrectly AlphaTest out pixels where alpha==0.0
Note to developers: Test your code on checkerboard backgrounds!
> Thx for helping identify the issue and providing a nice test case
> (please don't delete it. At least keep it for a few days, as I used
> the link in my bug report).
> On Mon, Nov 1, 2010 at 11:16 AM, <email@example.com> wrote:
>> Yep - it looks fine in the Canary build under Windows with
>> Presumably that's the difference though. Under Linux, Chrome is forced
>> 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
>> You're not seeing my problem with ANGLE right now because it's broken
>> 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 -
>> don't have the version number to hand right now) runs ANGLE OK - and
>> the background-leakage bug is more or less the same as in
>> 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.
>> -- Steve
>>> 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 <firstname.lastname@example.org> 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
>>>> 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
>>>> 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 email@example.com.
> To unsubscribe, send an email to firstname.lastname@example.org with
> the following command in the body of your email:
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: