Re: [css3-background] Where we are with Blur value discussion

On Fri, Jul 16, 2010 at 3:24 PM, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
> On Fri, Jul 16, 2010 at 4:17 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> Now, the relationship between stdev and blur length is clear.
>> Amazingly enough, if we define the length as "the distance from the
>> edge where it reaches 98% transparency", then the stdev we need to
>> produce that is just half the length.
>>
>> Yup, just divide the length by 2 and you have the appropriate stdev to
>> feed the guassian.  This relationship holds basically perfectly all
>> the way from 0 to 100stdevs (that is, 0 to 200px blur length).  This
>> approximation eventually fails, but I don't know if that's an actual
>> divergence or just actual floating point errors finally catching up to
>> me.  I'd want to run this with some infinite-precision arithmetic to
>> verify.
>
> So in other words you match the canvas spec exactly for an input of
> less than 8.  Would it be most reasonable to go with the canvas
> definition instead, then?  I guess it deviates way too much for large
> values, but it would be nice if they matched.

The <canvas> spec's treatment of inputs larger than 8 is *insane*.  To
do something as simple as a 20px blur, the necessary <canvas> input is
50.  That's silly.  If you were being crazy and wanted a 200px blur,
the necessary <canvas> input is *5000*.  That doesn't even make sense.

I agree they should match, but I think it should be done in the
reverse direction, by getting <canvas> to just always halve the input.
 CoreGraphics is just silly, and it's trivial to "correct" the stdev
into a proper input for CG.  We just need to get some implementors to
do that so we can file a bug on HTML5.


>> So, we have a relatively easy specification - just say that the blur
>> must approximate a gaussian with a stdev of half the blur length.
>> Then we can put up a little bit of language defining ranges that the
>> approximation must fall within, which we were already planning on.
>>
>> I'm gonna call this problem solved, then.
>
> There's still the problem of testing it, given that at least some
> browsers want to use approximations that aren't close to exact.
> (Maybe this will go away when everyone switches to hardware
> rendering?)

With a sufficiently forgiving range, it'll be fine.  This might end up
meaning that Chrome-using-Skia will fail for now because their shadows
are so ass-ugly when they get big, but other browsers do pretty
shadows, and that's enough.

~TJ

Received on Friday, 16 July 2010 22:44:07 UTC