Re: Margins for filters?

On Mon, 19 Apr 2010 12:37:42 +0200, Jasper van de Gronde  
<th.v.d.gronde@hccnet.nl> wrote:

> Erik Dahlstrom wrote:
>> On Mon, 19 Apr 2010 07:45:00 +0200, Robert O'Callahan  
>> <robert@ocallahan.org> wrote:
>>> I suggest we continue to allow filter primitive subregions to clip  
>>> filter
>>> primitives, but that we make the default filter primitive subregion  
>>> (for all
>>> filter primitives) be infinite so no clipping is performed.
>>  What you are suggesting is to allow the filter primitive subregion to  
>> be larger than the filter region, so calling it 'subregion' sounds  
>> wrong to me (editorial, but still, if that change is made I'd like to  
>> call it 'filter primitive region' instead).
>
> Okay, so basically the idea currently on the table would be to more or  
> less forget about the filter effects region and filterRes (and do the  
> same for masks), but keep filter primitive "subregions"? With the twist  
> that by default such a region would be infinite (conceptually). Have I  
> got that right?
>
> Something like that would indeed be nice. Although it might be good to  
> change an implementation to actually do that first, to see how well it  
> works in practice, and to evaluate the impact on existing images.
>
> For backwards compatibility we probably still should respect the filter  
> effects region if it is specified explicitly, but it might be reasonable  
> to simply change the default to being infinite (like with subregions).  
> Note that this does NOT mean that a renderer would be required to  
> actually store an infinite output, as obviously any viewport will be  
> finite and there are no IIR filter primitives (so to speak). So a  
> renderer could in principe "simply" render the required parts.
>
> Or, if an infinite filter effects region is deemed too problematic the  
> default could be made "auto", instructing the renderer to use the  
> required margins. These margins could be left upto the renderer in most  
> cases (or given a minimum?), and for filters like feFlood they could be  
> given very specific values.

I've raised ISSUE-2321 for this, and intend to address this in SVG Filters  
1.2.

It looks likely that the margin attributes will be dropped in favor of a  
new model like the one suggested here (although the backwards compat  
issues need to be worked out). Since Mozilla claims to have some  
bugreports on clipping to the filter effects region I'd like to ask for a  
listing of those bugs so that we might extract some testcases from the  
reports.

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Wednesday, 21 April 2010 19:40:25 UTC