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

On Thu, Jul 15, 2010 at 2:19 PM, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
> On Wed, Jul 14, 2010 at 7:19 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> *However*, I'm pretty certain we can't do that.  Gaussian blurs can be
>> *expensive*, and drawing shadows in CSS is a perf-sensitive matter.
>> Safari found that out directly - they use CoreGraphics to provide a
>> true gaussian blur, and it causes pretty crazy perf hits on some pages
>> that misuse shadows, while Chrome/Linux's use of the Skia graphics
>> library (which produces ugly shadows at large sizes) zooms through
>> them.
>
> I don't know why this isn't a problem for SVG too, but okay.

My only guess is that there isn't enough SVG that makes heavy use of
shadows for it to matter.  I am assured by multiple people on Webkit,
though, that gaussians are definitely expensive.  Even the triple
box-blur that is apparently used is turning out to be too expensive to
use for *all* shadows.


> It looks
> like no one uses a real Gaussian blur anyway for anything, they use an
> approximation that's provably correct to within 3% or so.  So we
> probably don't have exact matches if you sample the precise pixel
> colors.  If a browser needs to do something even less accurate, then
> of course, the spec can't prohibit that.  In that case, it should
> define a precise reference rendering (probably using Gaussian blurs)
> and then explicitly say browsers can approximate as much as they like,
> so how close you are to the reference rendering is a
> quality-of-implementation issue and not a conformance issue.  But some
> sort of reference should be there, so that browsers are at least
> trying to approximate the same thing and won't have greatly different
> ideas on what the values mean.

As I said before, I'm fine with providing an informative reference,
but that doesn't reduce our need to create some testable guarantees.


>> As spec
>> writers, we just need to do our part for authors and ensure that they
>> look approximately the same according to certain chosen metrics;
>> namely, that the shadow is a monotonic function, and the 99% point of
>> the function must occur at +/- 1% of the given length from the shadow
>> origin, or similar.  We can test that, and we can rely on browsers to
>> gradually do whatever maximizes the pretty/perf graph.
>
> You'd have to define that much more precisely for it to be testable.
> And it could still conflict with performance constraints, particularly
> in corner cases.

?_?  That sounds plenty testable to me.  Grab the pixels, verify they
form a gradient, then check where the 99% point is hit.  Sounds easy
to me.

The only performance impact of this is possibly reversing the length
into whatever input the shadow-drawing function needs.  If so, we can
loosen the requirement for larger shadows, where cheap approximations
aren't as accurate but the precision is less important.

I need to investigate and find a good cheap approximation.


>> * Heck, while we're all talking about gaussian blurs, *real shadows
>> aren't blurred by a gaussian*.  Real physical light is distributed
>> near a shadow edge via a subtly different function.  I see no reason
>> to prevent someone from using a more realistic shadow blur if they
>> want to burn the cycles on it.
>
> Authors aren't looking for physical realism, they're looking for a
> particular visual effect.  The standard tool for that is apparently
> Gaussian blurs.  If it's noticeably different from real shadows,
> people will probably prefer the fake ones anyway from familiarity.

Real shadow blurs aren't noticeably different from gaussians, but the
difference should be detectable.  I'm just saying, they could do it
they wanted.  ^_^  Anything that allows a gaussian short of an actual
pixel-reference should allow more realistic shadow blurs
automatically.

~TJ

Received on Thursday, 15 July 2010 21:42:18 UTC