Summary: | [CG] Incorrect rendering of SVG path by CoreGraphics | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Anthony Glenning <aglenning> | ||||||||
Component: | SVG | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED WORKSFORME | ||||||||||
Severity: | Normal | CC: | darin, koivisto, krit, mrowe, oliver, rwlbuis, zimmermann | ||||||||
Priority: | P2 | Keywords: | GoogleBug, HasReduction, InRadar | ||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | Mac | ||||||||||
OS: | OS X 10.5 | ||||||||||
Attachments: |
|
Description
Anthony Glenning
2008-08-27 18:34:47 PDT
Created attachment 23047 [details]
SVG file displaying the bug
Safari and Firefox on Mac OS X display the same behaviour. Firefox on Windows does not, while Safari on Windows does. This may be bug in the underlying graphics library, as a common factor between all of the browsers that demonstrate the bug is the underlying graphics library (CoreGraphics). Our rendering may be wrong. I'm not sure yet. There is also some craziness in the path your using: <svg viewBox="0.0 0.0 304800.0 228600.0" xmlns="http://www.w3.org/2000/svg"> <path d=" M107061 74105 L107061 74105 C107061 69370 110899 65532 115634 65532 L145510 65532 L145510 65532 L161989 65532 L164401 65532 C166675 65532 168855 66435 170463 68043 C172071 69651 172974 71831 172974 74105 L172974 95536 L172974 95536 L172974 108395 L172974 108394 C172974 113129 169136 116967 164401 116967 L161989 116967 L155829 159258 L145510 116967 L115634 116967 L115634 116967 C110899 116967 107061 113129 107061 108394 L107061 108395 L107061 95536 L107061 95536 Z" fill="none" stroke="#073763" stroke-width="13716.0" stroke-linejoin="round"> </path> </svg> That's a reduction of what you provided. Notice that a bunch of the line segments are repeated. Removing some of the repetitions makes the "holes" go away. Still investigating. Further reduction: <svg viewBox="0 0 300 200" xmlns="http://www.w3.org/2000/svg"> <path d=" M 173 80 L 173 108.01 L 173 108 C 173 113 169 117 164 117 " fill="none" stroke="#073763" stroke-width="13" stroke-linejoin="round"> </path> </svg> So the extra line segment is clearly redundant. The commands we're issuing to CoreGraphics (on behalf of the SVG author) are: 1. move to point (173, 80) 2. draw a line from the current point to (173, 108.01) 3. draw a line from the current point to (173, 108) // FireFox is possibly ignoring this command? 4. draw a bezier curve from the current point, using control points: (173, 113) and (169, 117) and ending at (164 117). Created attachment 23049 [details]
Further demonstration of CG's behavior
This may be expected behavior on CG's part. One of the Apple guys would need to ask one of the CG folks. My recommendation is that Google work around this behavior. I don't think we want WebKit trying to hack around this behavior.
I think the CG bug (if there is one) is that kCGLineJoinRound doesn't work as expected when the line backs up over itself: <svg viewBox="0 0 300 200" xmlns="http://www.w3.org/2000/svg"> <path d=" M 173 80 L 173 108.01 L 173 108 " fill="none" stroke="blue" stroke-width="13" stroke-linejoin="round"> </path> It would nice to get confirmation from the Apple folks that they believe this is a CG bug, and if so, then we can close this external bug. Created attachment 103103 [details]
Pure-CG repro.
Attaching a CG-only reduction which makes it look like it's definitely a CG bug, as behavior changes when the view is drawn with flipped coordinate space or not. I'll file it.
(In reply to comment #10) > Created an attachment (id=103103) [details] > Pure-CG repro. > > Attaching a CG-only reduction which makes it look like it's definitely a CG bug, as behavior changes when the view is drawn with flipped coordinate space or not. I'll file it. Can this be fixed in WebKit at all? Is it a WONTFIX? CC'ing Darin who might have the CG contact sot get this old bug sorted out! Maybe CG indeed fixed something. The attached examples work correctly in Safari. |