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

  -- Steve

> 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).
> Mo
> On Mon, Nov 1, 2010 at 11:16 AM,  <steve@sjbaker.org> wrote:
>> 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.
>>  -- 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.
>>> Mo
>>> On Sun, Oct 31, 2010 at 2:02 PM, Steve Baker <steve@sjbaker.org> wrote:
>>>> OK - I finally have a reasonably simple test case at:
>>>>    http://www.sjbaker.org/test/index.php
>>>> ...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
>>>>>    layers.accelerate-all=false
>>>>>    layers.accelerate-none=true
>>>>> 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 public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:

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: