Closed Bug 437704 Opened 12 years ago Closed 11 years ago

SVG rendering stops

Categories

(Core :: SVG, defect, P2, major)

x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla1.9.1b3

People

(Reporter: jesper, Assigned: longsonr)

References

()

Details

(Keywords: regression, verified1.9.1)

Attachments

(2 files, 3 obsolete files)

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.
Component: General → SVG
Product: Firefox → Core
Regression range is
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1191970380&maxdate=1191971339
= Bug 384681.
Blocks: 384681
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Version: unspecified → Trunk
QA Contact: general → general
Flags: blocking1.9.1?
which is cairo moving from 16.16
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
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.
Attached patch patch (obsolete) — Splinter Review
This patch includes the changes from bug 463934 too.
Assignee: nobody → longsonr
Status: NEW → ASSIGNED
Attachment #349072 - Flags: superreview?(roc)
Attachment #349072 - Flags: review?(roc)
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.
Attached patch alternate patch (obsolete) — Splinter Review
(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 :-)
Attachment #349257 - Flags: superreview?(roc)
Attachment #349257 - Flags: review?(roc)
Attached patch alternate patch (obsolete) — Splinter Review
Attachment #349257 - Attachment is obsolete: true
Attachment #349258 - Flags: superreview?(roc)
Attachment #349258 - Flags: review?(roc)
Attachment #349257 - Flags: superreview?(roc)
Attachment #349257 - Flags: review?(roc)
Attachment #349258 - Flags: superreview?(roc)
Attachment #349258 - Flags: superreview+
Attachment #349258 - Flags: review?(roc)
Attachment #349258 - Flags: review+
Attachment #349072 - Attachment is obsolete: true
Attachment #349072 - Flags: superreview?(roc)
Attachment #349072 - Flags: review?(roc)
Attached patch update to tipSplinter Review
Attachment #349258 - Attachment is obsolete: true
Pushed to trunk as 8a4f6b93e721
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 191 landing]
BTW could we get a reftest here?
Flags: in-testsuite?
Pushed 788d78eb3d9b to 1.9.1
Keywords: fixed1.9.1
Whiteboard: [needs 191 landing]
Target Milestone: --- → mozilla1.9.1b3
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
Status: RESOLVED → VERIFIED
Blocks: 483439
Attachment #377743 - Flags: review?(roc) → review+
pushed http://hg.mozilla.org/mozilla-central/rev/d2665f9dc8c1

Thanks Aaron.
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.