Bug 64675
| Summary: | [SVG] [Chromium] zero-path-square-cap-rendering.svg is failing | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> |
| Component: | Layout and Rendering | Assignee: | Stephen Chenney <schenney> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | jamesr, rwlbuis, schenney, tony, zimmermann |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 71820 | ||
| Bug Blocks: | |||
Ryosuke Niwa
Two tests added by http://trac.webkit.org/changeset/91125/ are failing on Chromium Linux:
Results:
http://build.webkit.org/results/Chromium%20Linux%20Release%20(Tests)/r91171%20(21141)/svg/W3C-SVG-1.1-SE/painting-control-04-f-diffs.html
http://build.webkit.org/results/Chromium%20Linux%20Release%20(Tests)/r91171%20(21141)/svg/custom/zero-path-square-cap-rendering-diffs.html
Flakiness dashboard:
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=svg%2FW3C-SVG-1.1-SE%2Fpainting-control-04-f.svg%2Csvg%2Fcustom%2Fzero-path-square-cap-rendering.svg&revision=91126&group=%40ToT%20-%20webkit.org
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Ryosuke Niwa
They are also failing on Chromium Windows:
http://build.webkit.org/results/Chromium%20Linux%20Release%20(Tests)/r91171%20(21141)/svg/W3C-SVG-1.1-SE/painting-control-04-f-diffs.html
http://build.webkit.org/results/Chromium%20Linux%20Release%20(Tests)/r91171%20(21141)/svg/custom/zero-path-square-cap-rendering-diffs.html
Rob Buis
Hi,
(In reply to comment #1)
> They are also failing on Chromium Windows:
>
> http://build.webkit.org/results/Chromium%20Linux%20Release%20(Tests)/r91171%20(21141)/svg/W3C-SVG-1.1-SE/painting-control-04-f-diffs.html
>
> http://build.webkit.org/results/Chromium%20Linux%20Release%20(Tests)/r91171%20(21141)/svg/custom/zero-path-square-cap-rendering-diffs.html
This should have improved after r91191.
Cheers,
Rob.
Ryosuke Niwa
Nope. They're still failing :( This might be Skia related.
Ryosuke Niwa
Committed r91211: <http://trac.webkit.org/changeset/91211>
Ryosuke Niwa
svg/W3C-SVG-1.1-SE/painting-control-04-f.svg is now passing but zero-path-square-cap-rendering.svg is not.
Rob Buis
Hi,
(In reply to comment #5)
> svg/W3C-SVG-1.1-SE/painting-control-04-f.svg is now passing but zero-path-square-cap-rendering.svg is not.
For anyone looking into the problem on chromium, one thing to check first is check that the m_fillBoundingBox width and height is really zero. This comes from Path which is platform specific. So, the question is what Skia returns for bbox of a path "M 100 100 Z", if width/height is not exactly zero, the new special handling of zero-length paths will not kick in.
Cheers,
Rob.
Stephen Chenney
This is Skia 398: http://code.google.com/p/skia/issues/detail?id=398
Skia throws away the closing "z" in "m 50 50 z" because it considers it redundant. This then causes the Skia SkPath::isEmpty call to fail because Skia considers a path "m 50 50" to be empty.
This makes it impossible to correctly implement SVG zero-length linecaps for such paths.
Stephen Chenney
This will be fixed with 71820, I hope.
Stephen Chenney
Changes r105878 and r105921 fix the issue.