- 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 http://granite.sru.edu/~ddailey/svg/backgroundBlur.svg 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? D 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. 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 16:01:14 UTC