437704 - SVG rendering stops

Status: VERIFIED FIXED

(Core :: SVG, defect, P2)

Description

[Jesper Hansen]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0

Somehow the SVG rendering between Fx2 and Fx3 is broken. 
While in Fx2 the rendering of this http://upload.wikimedia.org/wikipedia/commons/5/59/Average_gasoline_prices_by_country.svg is done right, then Fx3 fails it.
The end rendering is shown here:
http://upload.wikimedia.org/wikipedia/commons/thumb/5/59/Average_gasoline_prices_by_country.svg/800px-Average_gasoline_prices_by_country.svg.png

Reproducible: Always

Steps to Reproduce:
1. Visit svg image.
Actual Results:  
Visiting the svg image location starts rendering. Stops when is about to render the countries. Tabbing away from back to the svg image makes firefox render two countries but stops again.

Expected Results:  
A complete flawless rendering

Issue is confirmed by other Fx3 users.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Regression range is
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1191970380&maxdate=1191971339
= Bug 384681.

Comment 2

[Robert Longson [:longsonr]]

which is cairo moving from 16.16

Comment 3

[Robert Longson [:longsonr]]

Cairo does not calculate the bounding box of the stroked elements because the line width is so small (stroke-width: 0.0001;) that it rounds to zero in _compute_face in a 24.8 coordinate system.

Comment 4

[Robert Longson [:longsonr]]

Attachment: patch

This patch includes the changes from bug 463934 too.

Comment 5

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

Is it possible for stroke geometry to be slightly weird so that the extents we get are non-empty but wrong? Seems to me a simpler and more robust approach would be to just union the stroke and fill extents always.

Comment 6

[Robert Longson [:longsonr]]

Attachment: alternate patch

(In reply to comment #5)
> Is it possible for stroke geometry to be slightly weird so that the extents we
> get are non-empty but wrong? 

I don't think we've seen that. In this case the line width is so small that cairo won't draw the lines so it simply returns an empty rectangle.

> Seems to me a simpler and more robust approach
> would be to just union the stroke and fill extents always.

I like my way better as getting extents involves a fair amount of calculation; our way doubles that always whereas my way doubles it rarely. Weighted against that is that they are cached, I can't establish any clear performance impact in my ad-hoc testing and your way is more robust so I'm not going to die in a ditch over it :-)

Comment 7

[Robert Longson [:longsonr]]

Attachment: alternate patch

Comment 8

[Robert Longson [:longsonr]]

Attachment: update to tip

Comment 9

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

Pushed to trunk as 8a4f6b93e721

Comment 10

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

BTW could we get a reftest here?

Comment 11

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

Pushed 788d78eb3d9b to 1.9.1

Comment 12

[Tony Chung [:tchung]]

Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090217 Shiretoko/3.1b3pre Ubiquity/0.1.5 
and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090217 Minefield/3.2a1pre

Comment 13

[Aaron Train [:aaronmt]]

Attachment: thin-stroke-render reftest

Comment 14

[Robert Longson [:longsonr]]

pushed http://hg.mozilla.org/mozilla-central/rev/d2665f9dc8c1

Thanks Aaron.