647979 - SVG path clipping

Status: RESOLVED DUPLICATE of bug 1063486

(Core :: Graphics, 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

Gecko sometimes clips paths without any reason (specified in SVG).
The provided file has two sample paths with this behaviour.
Especially they have to cover the two red circles completely.

The bug appears, if stroke-linejoin is set to round or bevel, not for miter.

Reproducible: Always

Steps to Reproduce:
1. Use the sample at the URI above
2. Compare with the specification and behaviour of other viewers
Actual Results:  
Gecko clips the path somehow - why?
The red circles become visible, which should have been covered by the paths.
Other viewers do not show this behaviour and it is not specified anywhere nor
has it any functionality related to the document or SVG.

Expected Results:  
The paths have to cover the red circles completely.
There has to be no clipping (at least with the light yellow area representing the
viewBox).

Comment 1

[Robert Longson [:longsonr]]

I don't see this. Can you add a screenshot as an attachment please? Perhaps it's Linux only?

Comment 2

[Alex Lakatos[:AlexLakatos]]

Attachment: screenshot

This is how it looks on WinXP

Comment 3

[Dr. Olaf Hoffmann]

On Linux it is the same as for the WinXP screenshot.

I found other surpring disturbances in other files, not sure if they are related,
therefore maybe better to report them as different bugs ...

Comment 4

[Robert Longson [:longsonr]]

Displays correctly for me on Windows 7 with hardware acceleration.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to comment #3)
> On Linux it is the same as for the WinXP screenshot.

(confirming)
Mozilla/5.0 (X11; Linux i686; rv:2.2a1pre) Gecko/20110331 Firefox/4.2a1pre

Comment 6

[Boris Zbarsky [:bzbarsky]]

Sounds like a possible cairo issue?  This worksforme on Mac as well, so maybe an issue with Cairo paths?

Comment 7

[Bas Schouten (:bas.schouten)]

This does not happen on Direct2D either. It seems like a cairo bug. Since we're moving away from cairo I don't think we'll be investing a lot here to fix this. I'm keeping this open though since this is a fairly serious correctness issue, which might have to be dealt with for printing. Where we'll be working with Cairo for a little longer.

Comment 8

[Dr. Olaf Hoffmann]

Because this nasty bug appears now for years (last test with version 32), effectively resulting in the problem, that one cannot use a randomly created path at all, if one considers, that the user may use a Gecko viewer, I looked into this in more detail.

It turns out, that this bug is not necessarily related to stroking, it appears without as well - and pretty often for randomly created longer paths (more than 50% is wrong with a path consisting of about 50 cubic curve segments).
But it seems to be related to a wrong calculation of the bounding box of paths in combination with a surprising clipping box around paths (what has nothing to do with SVG at all, such a clipping box related to the bounding box around paths it simply wrong). However, this clipping box seems to be slightly larger than the wrongly calculated box for the stroked path and therefore parts of the path are missing.

Another example:
http://hoffmann.bplaced.net/mozilla/pathclipping.svg
the viewBox is indicated here and depending on the path structure the bug appears or not.
Clearly the problem is not related to the viewBox.
Here we compare two paths, a red one and a blue one.
The blue one has to cover the red one completely.
The end of the paths are the same. 

To explore the relation to the bounding box the same path example with bounding
boxes (if script interpretation is activated):
http://hoffmann.bplaced.net/mozilla/pathclippingjs.svg

If script interpretation is activated, additionally the two determined bounding boxes of the path are presented by gray rectangles. 
On the left the paths are different, therefore the boxes start at different x positions, but on the left the correct edge of the boxes are the same. 
In Gecko the boxes are different on the right, indicating a bug, maybe in relation to the wrong rendered paths.
It seems, that Gecko adds something like a border around the bounding box and uses this enlarged box errornously as a clipping area for the path presentation.

One can change the initial point of the blue path with a continuous declarative animation clicking on the blue path. 
Approximately the box result follows with a scripted animation.
At some position the bug vanishes suddenly, indicating that the problem seems to be related to some non local algorithm depending somehow on the complete path, not only the area, that vanishes under some conditions.

I think, as a first step one has to fix the determination of bounding boxes for paths. As a second step one has to remove this surprsing clipping behaviour from paths. Then the problem should be fixed completely.

Comment 9

[Tom Klein]

This was fixed by the patch for bug 1063486.