Re: Updated filters specification

On Tue, Apr 19, 2011 at 1:22 AM, Erik Dahlstrom <ed@opera.com> wrote:

> On Tue, 19 Apr 2011 06:23:57 +0200, Rik Cabanier <cabanier@gmail.com>
> wrote:
>
>  Hi Dean,
>>
>> This looks very good!
>>
>> A couple of questions:
>> 1. Filter region extensions.
>> Why do you need to specify this? I can see that this is necessary for
>> certain types of filters, but for the most common ones, the browser can
>> just
>> calculate if for you.
>> Could this be optional? It will for sure make author's life easier...
>>
>
> Yeah, that's been discussed before, and they're going away, I have an
> action to remove that (it's basically leftovers from an old SVG 1.2 Full
> draft).
>
>
>  2. Accessing the background image
>> Would there ever be a reason to do this? This seems like a very expensive
>> operation that could be worked around by rearranging the content.
>>
>
> You're right that it can be expensive to generate. I think in some (rare?)
> scenarios it is necessary to have something like enable-background.


A user could put the background content in with the content that has the
filter applied to it.
In addition to that, he would also have to draw a white box to make sure
that the actual background doesn't peek through where there's alpha.

This feature could be especially hard to implement in a world where things
are accelerated in the GPU


> There is also the SVG 1.1 backwards compatibility aspect to consider.


Do we care about this if we move to CSS? SVG1.1 was not designed for this.


>
> I think that the optional <x>,<y>,<width>,<height> values in
> 'enable-background' should be deprecated, because they are useless in
> practice. We should let the UA compute the necessary background buffer
> region, and just ignore these values if specified.


I agree. We can discuss that in the context of the SVG compositing spec.
Maybe there are workflows were this makes sense.

Rik