Last Comment Bug 467930 - Edges of blurred SVG shapes appear clipped due to renderer failing to expand their "bounding boxes"
: Edges of blurred SVG shapes appear clipped due to renderer failing to expand ...
Status: RESOLVED INVALID
: testcase
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: x86 Linux
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 470542 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-04 09:00 PST by Vladimir Dzhuvinov
Modified: 2009-02-10 13:42 PST (History)
10 users (show)
roc: wanted1.9.1+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
SVG test case with ellipse, rectangle and polygon shapes (9.19 KB, image/svg+xml)
2008-12-04 09:05 PST, Vladimir Dzhuvinov
no flags Details
testcase, reduced somewhat (535 bytes, image/svg+xml)
2009-02-10 03:19 PST, Jonathan Watt [:jwatt]
no flags Details
simpler testcase (306 bytes, image/svg+xml)
2009-02-10 06:31 PST, Robert Longson
no flags Details

Description Vladimir Dzhuvinov 2008-12-04 09:00:25 PST
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 2008-12-04 09:05:43 PST
Created attachment 351395 [details]
SVG test case with ellipse, rectangle and polygon shapes
Comment 2 Robert Longson 2008-12-19 05:00:49 PST
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 3 Robert Longson 2008-12-20 07:01:17 PST
*** Bug 470542 has been marked as a duplicate of this bug. ***
Comment 4 Thomas Goldstein 2008-12-20 12:57:31 PST
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 2008-12-20 14:26:24 PST
Bug 407542 does not work for me on Firefox 3.0.x. It is cut off at the bottom.
Comment 6 Jonathan Watt [:jwatt] 2009-02-10 03:19:52 PST
Created attachment 361491 [details]
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 2009-02-10 03:25:14 PST
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) (Exited; email my personal email if necessary) 2009-02-10 03:29:19 PST
Someone want to go out on a limb and mark it so? :-)
Comment 9 Robert Longson 2009-02-10 06:09:47 PST
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 2009-02-10 06:31:17 PST
Created attachment 361504 [details]
simpler testcase

Even simpler testcase shows that if you get the bounds right it doesn't clip.
Comment 11 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2009-02-10 10:49:23 PST
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 2009-02-10 13:42:34 PST
(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

Note You need to log in before you can comment on or make changes to this bug.