Re: [SVG11] filter subregion

On 2/12/07 7:51 AM, Erik Dahlström wrote:
> ASV3, Batik 1.6 and Opera 9.1 all displayed your example below exactly 
> the same.
> Firefox 3.0 (GranParadiso) looked the same except that it showed the 
> green circle.
> What implementations did you test?

It's been over a year since I asked for clarification on this issue, so 
I don't remember exactly what I was testing with.  Likely mozilla trunk, 
a Webkit nightly, ASV3, Batik 1.5 or 1.6, and whatever version of Opera 
was available in beta or release at the time.

> The expected result is that since the output of the 'feFlood' filter 
> primitive gives the result of the filter as a whole in this example the 
> red rect which is the 'feFlood' subregion will be what's visible of the 
> filtered element (the circle). Pixels outside of the filter primitive 
> subregion are set to transparent black, from reading the intro section 
> [1] which says:
> "Sometimes filter primitives result in undefined pixels. For example, 
> filter primitive 'feOffset' can shift an image down and to the right, 
> leaving undefined pixels at the top and left. In these cases, the 
> undefined pixels are set to transparent black."

I agree that feOffset can produce pixels that have an undefined value 
which need to be filled with some value, and transparent black is best. 
  feFlood doesn't have create undefined pixels - pixels in the subregion 
it affects are set to a certain value, while those outside should be 
left alone.

>  From reading section 15.7.3: "All filter primitives have attributes x, 
> y, width and height which identify a subregion which restricts 
> calculation and rendering of the given filter primitive."
> 
> Explain then how it's possible to get anything outside of the filter 
> primitive subregion as the result of the filter. Yes the filter 
> primitive can "leave the rest of the image alone", but that doesn't mean 
> that the "SourceGraphic" (the default value for 'in' to the filter 
> primitive) isn't clipped by the filter primitive subregion, according to 
> 15.7.3: "x, y, width and height act as a hard clip clipping rectangle."

I read "hard clipping rectangle" as "hard clipping rectangle for the 
area affected by the filter element, pixels outside this region should 
be left alone."  Since the filter is larger than the element subregion, 
those pixels in the SourceGraphic input image (in this example) should 
be passed through.

> Compare with this similar testcase where the feFlood element has been 
> replaced by a feBlend element:
> 
> <svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">
> 
> <filter id="flood">
>    <feBlend x="25%" y="25%" width="50%" height="50%"
>             in2="SourceGraphic" mode="multiply"/>
> </filter>
> 
> <g fill="none" stroke="blue" stroke-width="4">
>    <rect width="200" height="200"/>
>    <line x2="200" y2="200"/>
>    <line x1="200" y2="200"/>
> </g>
> 
> <circle fill="green" filter="url(#flood)" cx="100" cy="100" r="90"/>
> 
> </svg>
> 
> Batik 1.6 shows this one correctly, there should be no circle visible 
> only a dark rect. Opera 9.1 and ASV3 don't clip the filter primitive 
> correctly in this case, but filters the given filter primitive subregion 
> only. Firefox 3.0 calculated the filter result outside of the filter 
> primitive subregion.

Thanks for the testcase - pointed out a couple unrelated problems in our 
implementation.  Those aside, Firefox trunk and Opera 9.1 give the same 
result - the filter applied to the subregion (giving a darker green 
rect), and the filter passing through the rest of the green circle.

> Given the explanation I've made here, do you still think it needs 
> clarification? Would having the examples in this mail along with section 
> 15.7.3 in the svg 1.1 errata be enough to satisfy you or would it be 
> sufficient to add the same to the new filter specification?

I think the language still needs clarification/errata, since I read a 
different meaning from it than you do.

Received on Thursday, 15 February 2007 22:23:27 UTC