Last Comment Bug 647687 - wrong filter area / clipping for stroke, with SVG feOffset
: wrong filter area / clipping for stroke, with SVG feOffset
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla9
Assigned To: Robert Longson
:
Mentors:
http://hoffmann.bplaced.net/svgtest/f...
: 694725 (view as bug list)
Depends on: 619992 684479
Blocks: 484067
  Show dependency treegraph
 
Reported: 2011-04-04 08:41 PDT by Dr. Olaf Hoffmann
Modified: 2011-12-18 15:12 PST (History)
7 users (show)
longsonr: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase 1 (no red should be visible) (858 bytes, image/svg+xml)
2011-04-08 14:00 PDT, Daniel Holbert [:dholbert]
no flags Details
fix SourceImage bounds (originally from bug 619992) (3.47 KB, patch)
2011-08-21 10:21 PDT, Robert Longson
longsonr: review+
Details | Diff | Review
tighten covered rect for shapes and add test (4.77 KB, patch)
2011-08-21 10:22 PDT, Robert Longson
no flags Details | Diff | Review
update to tip and add tests (5.53 KB, patch)
2011-09-14 22:03 PDT, Robert Longson
no flags Details | Diff | Review

Description Dr. Olaf Hoffmann 2011-04-04 08:41:58 PDT
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.
Comment 1 Boris Zbarsky [:bz] 2011-04-04 15:23:59 PDT
Daniel, Robert, could you take a look?
Comment 2 Daniel Holbert [:dholbert] 2011-04-08 14:00:32 PDT
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.)
Comment 3 Robert Longson 2011-04-09 10:41:48 PDT
This is fixed by the patches in bug 619992.
Comment 4 Robert Longson 2011-08-21 10:21:41 PDT
Created attachment 554730 [details] [diff] [review]
fix SourceImage bounds (originally from bug 619992)
Comment 5 Robert Longson 2011-08-21 10:22:34 PDT
Created attachment 554731 [details] [diff] [review]
tighten covered rect for shapes and add test
Comment 6 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-08-21 14:47:04 PDT
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.
Comment 7 Robert Longson 2011-09-03 05:13:35 PDT
(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.
Comment 8 Robert Longson 2011-09-14 22:03:47 PDT
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.
Comment 10 Ed Morley [:emorley] 2011-09-18 12:27:53 PDT
https://hg.mozilla.org/mozilla-central/rev/87ce16809ea0
Comment 11 Daniel Holbert [:dholbert] 2011-10-14 19:47:50 PDT
*** Bug 694725 has been marked as a duplicate of this bug. ***

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