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

On Wed, Jul 14, 2010 at 7:19 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> That part's not acceptable.  Authors win over implementors in general,
> and in this case having the authors perform mental math or
> guess-and-check every single time they use a shadow (or force them to
> develop an intuition for it) versus implementors figuring out the
> proper conversion once and putting that in their code isn't even a
> contest.  Authors win.

Okay, sure, if that's doable.

> *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.  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 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.

> * 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.

Received on Thursday, 15 July 2010 21:19:52 UTC