Closed
Bug 437704
Opened 17 years ago
Closed 16 years ago
SVG rendering stops
Categories
(Core :: SVG, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla1.9.1b3
People
(Reporter: jesper, Assigned: longsonr)
References
()
Details
(Keywords: regression, verified1.9.1)
Attachments
(2 files, 3 obsolete files)
2.41 KB,
patch
|
Details | Diff | Splinter Review | |
965 bytes,
patch
|
longsonr
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•17 years ago
|
Component: General → SVG
Product: Firefox → Core
Comment 1•17 years ago
|
||
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
Updated•17 years ago
|
QA Contact: general → general
![]() |
||
Updated•17 years ago
|
Flags: blocking1.9.1?
Assignee | ||
Comment 2•17 years ago
|
||
which is cairo moving from 16.16
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Assignee | ||
Comment 3•16 years ago
|
||
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.
Assignee | ||
Comment 4•16 years ago
|
||
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.
Assignee | ||
Comment 6•16 years ago
|
||
(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)
Assignee | ||
Comment 7•16 years ago
|
||
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+
Assignee | ||
Updated•16 years ago
|
Attachment #349072 -
Attachment is obsolete: true
Attachment #349072 -
Flags: superreview?(roc)
Attachment #349072 -
Flags: review?(roc)
Whiteboard: [needs landing]
Assignee | ||
Comment 8•16 years ago
|
||
Attachment #349258 -
Attachment is obsolete: true
Pushed to trunk as 8a4f6b93e721
Status: ASSIGNED → RESOLVED
Closed: 16 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]
Updated•16 years ago
|
Target Milestone: --- → mozilla1.9.1b3
Comment 12•16 years ago
|
||
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
Keywords: fixed1.9.1 → verified1.9.1
Comment 13•16 years ago
|
||
Attachment #377743 -
Flags: review?(roc)
Assignee | ||
Updated•16 years ago
|
Attachment #377743 -
Flags: review?(roc) → review+
Assignee | ||
Comment 14•16 years ago
|
||
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.
Description
•