467930 - Edges of blurred SVG shapes appear clipped due to renderer failing to expand their "bounding boxes"

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[Vladimir Dzhuvinov]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092816 Iceweasel/3.0.3 (Debian-3.0.3-3)
Build Identifier: Gecko 1.9.1b1 (20081007112159)

I've noticed that Mozilla clips the edges of SVG shapes that have been applied a blur filter. It appears the renderer creates some kind of a bounding box around shapes, but fails to expand it correctly after the blur is applied, so the edges of the filtered shape can appear clipped. This clipping effect is most pronounced with blur radii between 5 and 15px.



Reproducible: Always

Actual Results:  
Here is a small test SVG to show the problem (generated with Inkscape,
exported as "plain SVG"):
http://valan.net/tmp/mozilla/clipped_edges_of_blurred_shapes.test.svg

Here is the Inkscape output, which looks fine:
http://valan.net/tmp/mozilla/clipped_edges_of_blurred_shapes.inkscape-output.png

Here is the Mozilla (FF 3.1 beta) output where the four edges appear
clipped:
http://valan.net/tmp/mozilla/clipped_edges_of_blurred_shapes.mozilla-output.png


Observed in FF3.0.*, 3.1beta, xulrunner 1.9.0.4

Comment 1

[Vladimir Dzhuvinov]

Attachment: SVG test case with ellipse, rectangle and polygon shapes

Comment 2

[Robert Longson [:longsonr]]

We use GetBBox to get the filter bounding box but this gives the tight bounding box which excludes the stroke width. We need to use something akin to the covered region in appropriate units.

Comment 4

[Thomas Goldstein]

Bug 470542, that I reported, indeed looks like a duplicate of this one at first sight... However, the difference is that mine was a regression (worked fine with Firefox 3.0.x). This bug, on the other hand, is not a regression.

Comment 5

[Robert Longson [:longsonr]]

Bug 407542 does not work for me on Firefox 3.0.x. It is cut off at the bottom.

Comment 6

[Jonathan Watt [:jwatt]]

Attachment: testcase, reduced somewhat

I'm not sure what you mean by comment 2, Robert. We use the bbox to do objectBoundingBox calculations, but that's per-spec.

I'm not convinced that this is a bug in Mozilla. I think it's just as likely that the filter region defined by the x, y, width and height attributes on the <filter> element is too small, and that's what's causing the clipping. Probably Inkscape tries to set these to produce the smallest filter region possible that will not clip the results, but it could well be getting the calculation wrong. Or perhaps we are. Someone needs to do the math to figure out who's to blame. :-) Of course, arguably the spec is to blame for requiring users to specify the filter region and not allowing the implementation to figure out the optimal size automatically.

Comment 7

[Robert Longson [:longsonr]]

You are right. Per http://www.w3.org/TR/SVG/coords.html#ObjectBoundingBox the bounding box does not include stroke-width so this bug is invalid.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Someone want to go out on a limb and mark it so? :-)

Comment 9

[Robert Longson [:longsonr]]

Feel free to reopen if you can prove that the bounding box for the filters are sufficient to include both the shapes and the stroke-width of the shapes. Simpler examples i.e. a rect with a large stroke width and a filter would help rather than things composed of paths.

Comment 10

[Robert Longson [:longsonr]]

Attachment: simpler testcase

Even simpler testcase shows that if you get the bounds right it doesn't clip.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The filter region stuff in the spec is a real disaster. This isn't the first time that we've followed the spec when others haven't and authors blame us. It's awfully tempting to just stop clipping to the filter region, use the code we already have to figure out the optimal offscreen size, and get the spec changed. It's hard to image that content actually *relies* on this clipping.
http://weblogs.mozillazine.org/roc/archives/2008/02/the_best_of_int.html

Comment 12

[Doug Schepers]

(In reply to comment #11)
> The filter region stuff in the spec is a real disaster. This isn't the first
> time that we've followed the spec when others haven't and authors blame us.
> It's awfully tempting to just stop clipping to the filter region, use the code
> we already have to figure out the optimal offscreen size, and get the spec
> changed. It's hard to image that content actually *relies* on this clipping.
> http://weblogs.mozillazine.org/roc/archives/2008/02/the_best_of_int.html

I agree with you, ROC.  I think we've talked about this in the SVG WG before, and I will ask ED of Opera (Filters module editor) if he concurs.

http://www.w3.org/Graphics/SVG/WG/track/issues/2223