User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0 A wrong filter area is used for the offset, respectively the filtered circle is clipped for the blue stroked circle. The red stroked circle behind shows a red circle simulating the correct appearence. The blue circle should always cover the red one completely. Reproducible: Always Steps to Reproduce: 1. Use sample given at the URI above 2. Compare with description within the file, specification, behaviour of the adobe plugin or Opera (any version 9 to 11). Actual Results: Parts of the red stroked circle become visible, indicating the wrong clipping respectively the wrong filter area for the blue stroked circle. Expected Results: Blue stroked circle has to cover always completely the red stroked circle. Similar problems appear quite often with or without animation for many SVG filters. If required, I can provide more samples.
Daniel, Robert, could you take a look?
Created attachment 524728 [details] testcase 1 (no red should be visible) Here's a reduced testcase. For correct rendering, no red should be visible. This testcase contains two circles, one red and one blue, with the exact same filter & position. The red circle is just painted using 'fill'. The blue circle is a little smaller, but it has a stroke that stretches it out to the same 'effective size' as the red circle. (However, it looks like we're clipping its stroked region a bit overzealously.)
Created attachment 554730 [details] [diff] [review] fix SourceImage bounds (originally from bug 619992)
Created attachment 554731 [details] [diff] [review] tighten covered rect for shapes and add test
aIsMarkable should be an enum instead of a boolean; boolean parameters suck. Does this bug boil down to requiring that PathExtentsToMaxStrokeExtents return an exact result? Because if it does, this patch doesn't fix it.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #6) > aIsMarkable should be an enum instead of a boolean; boolean parameters suck. > > Does this bug boil down to requiring that PathExtentsToMaxStrokeExtents > return an exact result? Because if it does, this patch doesn't fix it. I've redone this patch in a new bug without the boolean parameter. That can land anyway as it's an improvement to what we have now. I'm still investigating whether we need an exact result for this bug's main patch to land.
Created attachment 560302 [details] [diff] [review] update to tip and add tests > Does this bug boil down to requiring that PathExtentsToMaxStrokeExtents > return an exact result? Because if it does, this patch doesn't fix it. It seems not to. I've included a reftest with a polygon where we still calculate larger bounds than required. I flood that with red and then put a lime rect on top with the correct bounds and the filter does not overspill. I'll land this in a couple of days to make sure get a different regression range than bug 619992.