647687 - wrong filter area / clipping for stroke, with SVG feOffset

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Dr. Olaf Hoffmann]

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 [:bzbarsky]]

Daniel, Robert, could you take a look?

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: 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 [:longsonr]]

This is fixed by the patches in bug 619992.

Comment 4

[Robert Longson [:longsonr]]

Attachment: fix SourceImage bounds (originally from bug 619992)

Comment 5

[Robert Longson [:longsonr]]

Attachment: tighten covered rect for shapes and add test

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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 [:longsonr]]

(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 [:longsonr]]

Attachment: 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 9

[Robert Longson [:longsonr]]

pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/87ce16809ea0

Comment 10

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/87ce16809ea0