Re: Updated filters specification

On 20/04/2011, at 6:58 AM, Rik Cabanier wrote:

> 
> 
> 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

It's also worth noting that you could implement the shorthand effects without having a full 'filter'/SVG engine. The shorthands don't need enable-background.

(We need a term for the previously-SVG part of the Filters spec. "Shorthands" works ok for the new part. I was going to say "XML" for the other part, but it isn't strictly XML any more. "Markup" doesn't work so well since everything is markup - same with "declarative").

Dean


>  
> 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