- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Fri, 16 Jul 2010 18:24:48 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Brad Kemper <brad.kemper@gmail.com>, "L. David Baron" <dbaron@dbaron.org>, Simon Fraser <smfr@me.com>, Brendan Kenny <bckenny@gmail.com>, www-style list <www-style@w3.org>
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. > 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?)
Received on Friday, 16 July 2010 22:25:23 UTC