- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Thu, 3 Jul 2008 10:35:27 +1200
- To: www-svg@w3.org
- Message-ID: <11e306600807021535x1517ac6euc07d5a33b12c109c@mail.gmail.com>
> > > 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 UTC