Closed Bug 437704 Opened 12 years ago Closed 11 years ago
SVG rendering stops
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.
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.
This patch includes the changes from bug 463934 too.
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.
(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 :-)
Whiteboard: [needs landing]
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?
Pushed 788d78eb3d9b to 1.9.1
Whiteboard: [needs 191 landing]
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
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.