RESOLVED INVALID 77020
[Qt]: SVG Bounding boxes are wrong for zero-length subpaths 
https://bugs.webkit.org/show_bug.cgi?id=77020
Summary [Qt]: SVG Bounding boxes are wrong for zero-length subpaths
Stephen Chenney
Reported 2012-01-25 09:48:07 PST
The bounding rectangles for zero length paths are not right when shown in LayoutTest results. They may or may not be correct at runtime when used for clipping etc. THis needs further investigation. Not that inconsistency in the reported bounds was present before the fix for 71820 was put in. This is an area that has been odd for quite some time.
Attachments
Add attachment proposed patch, testcase, etc.
Balazs Kelemen
Comment 1 2012-01-25 10:05:05 PST
Skipped tests on Qt: http://trac.webkit.org/changeset/105889 We should unskip them after fix.
Stephen Chenney
Comment 2 2012-01-26 11:55:02 PST
The problematic test cases are: LayoutTests/svg/W3C-SVG-1.1-SE/painting-control-04-f.svg LayoutTests/svg/custom/zero-path-square-cap-rendering.svg LayoutTests/svg/stroke/zero-length-arc-linecaps-rendering.svg and probably LayoutTests/svg/stroke/* The problem appears to be due to the interaction between platform/gaphics/qt/PathQt.cpp and RenderSVGShape::updateCachedBoundaries(). The underlying behavior of Qt's QPainterPath implementation may be to blame. Regardless, this issue seems to be Qt only. Not Chromium or Mac. Working through RenderSVGShape::updateCachedBoundaries() for the second path element, looking at how it computes m_repaintBoundingBox, which is the thing reported by DumpRenderTree: - The paths in question should not be empty, and according to comments in PathQt.cpp, they will not be. The comment may be incorrect. - The path should be detected as being of zero subpath length, triggering the uniting of the (initially zero sized bound) with the zero length stroke rectangle bound. Check that the offending paths actually have been detected as zero length. - Then marker bounds are added, which cannot make the path smaller, so probably is not the issue. - Then the repaint rect is set, which should be the zero-length-stroke bound size. - The only other way it could go wrong is if the resources intersection decides it has a zero sized clip or something. Hope that helps whomever comes to look at this.
Ádám Kallai
Comment 3 2012-10-10 08:51:53 PDT
Is Anybody working this bug?
Jocelyn Turcotte
Comment 4 2014-02-03 03:19:49 PST
=== Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary. If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.
Note You need to log in before you can comment on or make changes to this bug.