How much background content gets blurred by feGaussianBlur

I'm not quite sure what to expect here.

 

http://granite.sru.edu/~ddailey/svg/backgroundBlur.svg 

 

In this example two blurry patches are placed above some content. One patch
has not had its filter restricted in scope, the other has had the filter
confined by

 

<filter id="H" x="5%" y="5%" width="90%" height="90%">

 

Opera, Chrome and ASV render the overall result on left and right roughly
the same. The opacity of the center of the ellipses at left and right are
basically equivalent.

 

FF makes the confined patch, on right, considerably more opaque than the one
on the left. 

 

I think this is due to disallowing null pixels (white) from outside the
primitive filter coordinates from being averaged into the overall result,
since they are "out of bounds." The other browsers apparently do not see it
the same way.

 

Setting  primitiveUnits = "objectBoundingBox" does not eliminate the browser
differences (resulting in some rather odd results), nor does filterUnits or
filterRes. (though animating filterRes as in
http://granite.sru.edu/~ddailey/svg/filterResAnimateBlur.svg yields some
interesting results that once again serve to differentiate the behavior of
these four browsers with Opera and ASV agreeing and Chrome being different
and FF apparently not viewing the attribute as animateable)

 

The spec (1.1 revised) says:

 

" The standard deviation for the blur operation. If two
<http://www.w3.org/TR/SVG11/types.html#DataTypeNumber> <number>s are
provided, the first number represents a standard deviation value along the
x-axis of the coordinate system established by attribute
<http://www.w3.org/TR/SVG11/filters.html#FilterElementPrimitiveUnitsAttribut
e> 'primitiveUnits' on the
<http://www.w3.org/TR/SVG11/filters.html#FilterElement> 'filter' element."
filterUnits, primitiveUnits and filterRes, all seem to be things that might
control it, but how they would do so and what the defaults might be is what
I'm not sure of.

 

In short, it's not clear to me if the spec resolves the proper behavior
here, though I am probably missing something.

 

Cheers

David

Received on Sunday, 30 October 2011 15:52:23 UTC