Closed
Bug 1369904
Opened 7 years ago
Closed 7 years ago
SVG getBBox & objectBoundingBox units are incorrect on Mac/Android
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
FIXED
mozilla56
Tracking | Status | |
---|---|---|
firefox56 | --- | fixed |
People
(Reporter: amelia.bellamy.royds, Assigned: longsonr)
Details
Attachments
(1 file, 1 obsolete file)
1.84 KB,
patch
|
lsalzman
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce: 1. Create an SVG path where the control points of Bezier curves extend outside the bounding box (the tight rectangle that encloses all points on the path itself). 2. Apply a gradient or pattern that is scaled to use `objectBoundingBox` units to this path 3. View it in a version of Firefox that uses Skia as the underlying graphics library (Mac or Android) or 2. Query `getBBox()` on the path element on one of the problematic operating systems. or Run test case: https://codepen.io/AmeliaBR/pen/dRyPJE/?editors=1111 Actual results: The gradient is scaled too large, matching the too-large getBBox rectangle that includes the control points. Expected results: The bounding box should be scaled to the fill-region bounding box; it should not be affected by control points. In the linked demo, this means that all the gradients should have the same scale and same bounding box printed to the console (x=0, y=0, width=100, height=100). ___________________________ Firefox on Windows and Linux has the correct results. IE/Edge are also correct. Current versions of Blink and WebKit return correct results for getBBox, but use the too-large box for objectBoundingBox scaling. Per Chromium but https://bugs.chromium.org/p/chromium/issues/detail?id=230599: > The current implementation relies on SkPath::getBounds(), which computes a conservative result (includes control points). > Use SkPathOps::TightBounds() instead, for an exact answer. I assume the same problem and solution apply for Firefox.
Assignee | ||
Comment 1•7 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=96759cd50dc613ace7049307e6bf0d7bd5b74e50
Assignee | ||
Updated•7 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•7 years ago
|
||
Assignee: nobody → longsonr
Attachment #8874178 -
Flags: review?(jmuizelaar)
Comment 3•7 years ago
|
||
Comment on attachment 8874178 [details] [diff] [review] patch with test Review of attachment 8874178 [details] [diff] [review]: ----------------------------------------------------------------- I'll let Lee take this one.
Attachment #8874178 -
Flags: review?(jmuizelaar) → review?(lsalzman)
Comment 4•7 years ago
|
||
Comment on attachment 8874178 [details] [diff] [review] patch with test It would be simpler to just call mPath.computeTightBounds() instead of mPath.getBounds(). This way we don't have to separately call TightBounds and don't need to import the SkPathOps.h header either.
Assignee | ||
Comment 5•7 years ago
|
||
that's simpler, thanks for the suggestion Lee.
Attachment #8874178 -
Attachment is obsolete: true
Attachment #8874178 -
Flags: review?(lsalzman)
Attachment #8876980 -
Flags: review?(lsalzman)
Updated•7 years ago
|
Attachment #8876980 -
Flags: review?(lsalzman) → review+
Assignee | ||
Comment 6•7 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=ea1a841159155dd96f4fc434f6d8b958a6913375&selectedJob=106772493
Pushed by longsonr@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/3e62702024b0 Bounding box should not include control points. r=lsalzman
Comment 8•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/3e62702024b0
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox56:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
You need to log in
before you can comment on or make changes to this bug.
Description
•