wrong filter area / clipping for stroke, with SVG feOffset

RESOLVED FIXED in mozilla9

Status

()

Core
SVG
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: Dr. Olaf Hoffmann, Assigned: Robert Longson)

Tracking

Trunk
mozilla9
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

7 years ago
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
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.)
Version: unspecified → Trunk
Summary: wrong filter area / clipping for SVG feOffset → wrong filter area / clipping for stroke, with SVG feOffset
(Assignee)

Comment 3

7 years ago
This is fixed by the patches in bug 619992.
Depends on: 619992
(Assignee)

Updated

6 years ago
Assignee: nobody → longsonr
(Assignee)

Comment 4

6 years ago
Created attachment 554730 [details] [diff] [review]
fix SourceImage bounds (originally from bug 619992)
Attachment #554730 - Flags: review+
(Assignee)

Comment 5

6 years ago
Created attachment 554731 [details] [diff] [review]
tighten covered rect for shapes and add test
Attachment #554731 - Flags: review?(roc)
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.
(Assignee)

Updated

6 years ago
Depends on: 684479
(Assignee)

Updated

6 years ago
Attachment #554731 - Attachment is obsolete: true
Attachment #554731 - Flags: review?(roc)
(Assignee)

Comment 7

6 years ago
(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.
(Assignee)

Comment 8

6 years ago
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.
Attachment #554730 - Attachment is obsolete: true
(Assignee)

Comment 9

6 years ago
pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/87ce16809ea0
(Assignee)

Updated

6 years ago
Flags: in-testsuite+
https://hg.mozilla.org/mozilla-central/rev/87ce16809ea0
Status: NEW → RESOLVED
Last Resolved: 6 years ago
OS: Linux → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
Duplicate of this bug: 694725
(Assignee)

Updated

6 years ago
Blocks: 484067
You need to log in before you can comment on or make changes to this bug.