W3C home > Mailing lists > Public > www-svg@w3.org > July 2008

Re: SVG 1.2 filter region extensions

From: Robert O'Callahan <robert@ocallahan.org>
Date: Thu, 3 Jul 2008 10:35:27 +1200
Message-ID: <11e306600807021535x1517ac6euc07d5a33b12c109c@mail.gmail.com>
To: www-svg@w3.org
>
>
> In general it's useful to give control to the author, since even if a UA
> does have the kinds of optimizations you talk about there are cases where
> the filter region is smaller than what the UA can effectively estimate.
> And a reduction in the filtered area usually means that the content
> performs better, which should be what people want.
>
>
Sure. But I can't think of any realistic use cases that the filter-margins
extension would help with that my optimizations don't already capture.

What we do is not hard. We do a forward pass through the filter primitive
graph, computing bounding-boxes for the output of each filter primitive.
(For example, feGaussianBlur inflates its input bounding box by radii easily
computed from the standard deviations and knowledge of the box-blur
algorithm.) Then we do a backward pass through the primitives computing
which region of each primitive's output is actually needed. (For example, if
the second input to an feComposite operator="in" has a small bounding-box,
we can restrict the output of the first input to that area.) Our code is of
course available if anyone wants to look for details. This optimization
works brilliantly for typical drop shadows, since that was the problem that
motivated the work in the first place. Are there any other use cases you're
concerned about?

As a bonus, it's easy to add information about the dirty rect to the
needed-bounding-boxes pass, so you can restrict filter computation to the
minimum box needed to get correct results for the dirty area, for big
performance wins in cases like scrolling.

If there was a way of specifying <filter width="100%+2px"
> height="50%+3em"> for example, then the use-cases that filter-margins try
> to cover would be addressed. This is the only thing that the filter
> margins solve currently AFAIK, that you can have both
> objectBoundingBox-relative coordinates and userSpace/absolute coordinates
> at the same time and that they're added up to make the filter primitive
> subregion.
>
>
As I indicated in another email, I would love to have such composite length
values. But I don't see a need for them here.

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]
Received on Wednesday, 2 July 2008 22:36:06 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:39 GMT