W3C home > Mailing lists > Public > www-svg@w3.org > October 2011

RE: How much background content gets blurred by feGaussianBlur

From: David Dailey <ddailey@zoominternet.net>
Date: Sun, 30 Oct 2011 12:00:45 -0400
To: "'David Dailey'" <ddailey@zoominternet.net>, "'www-svg'" <www-svg@w3.org>
Message-ID: <001501cc971d$1573fb30$405bf190$@net>
On a related note, there is considerable between browser difference in how
the document responds to resizing the window in



Firefox redraws the blurred ellipses dynamically; Chrome waits until mouseup
to redraw; Opera requires a refresh; ASV doesn't understand the relative
coordinates and hence doesn't redraw at all.


Is that something the spec addresses?




From: David Dailey [mailto:ddailey@zoominternet.net] 
Sent: Sunday, October 30, 2011 11:52 AM
To: 'www-svg'
Subject: How much background content gets blurred by feGaussianBlur


I'm not quite sure what to expect here.




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



Received on Sunday, 30 October 2011 16:01:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:32 UTC