Re: Minutes From Filter Meeting, Next Steps

Hey, sorry I couldn't make the first meeting and didn't find out about the
second meeting until after it happened (if it did happen).

Vladimir Vukčević discovered that some of the content we're concerned about
rendering very slowly with filters (http://ejohn.org/files/ecma-cloud.svg)
is autogenerated with primitiveUnits="userSpaceOnUse" and default
x/y/width/height on the <filter> elements, and applies filters to a number
of elements in the document. Our implementation pretty much follows the spec
directly, creating a temporary surface 120% of the size of the viewport in
each direction and doing the blur over that surface for each element!
There's an obvious optimization to propagate bounding boxes through the
filter pipeline so we can create and compute over temporary surfaces smaller
than the official filter subregion for each filter element. That should help
performance quite a bit and I expect we can do it for FF3.

Of course our pure CPU implementation is still going to be quite slow for
complex animated content. I like Oliver's suggestion of picking a default
filterRes that's lower than normal for that case --- on the assumption that
authors generally won't specify filterRes (except for feConvolveMatrix, oh
well). We'll need to figure out a policy for that.

I still think a filter-rendering property or something like it has value.
But if people can't agree on it, I think we will be able to get by without
it in most cases.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]