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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.)
Summary: wrong filter area / clipping for SVG feOffset → wrong filter area / clipping for stroke, with SVG feOffset
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.
> 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.
Attachment #554730 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 8 years ago
OS: Linux → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
You need to log in before you can comment on or make changes to this bug.