| Summary: | Miter artifact for dashed strokes. | ||
|---|---|---|---|
| Product: | cairo | Reporter: | M Joonas Pihlaja <jpihlaja> |
| Component: | general | Assignee: | Carl Worth <cworth> |
| Status: | RESOLVED MOVED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 1.8.1 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Miter quad where it shouldn't be.
Output of dash-and-miter.c Current behaviour for degenerate dashes PS behaviour Quartz behaviour |
||
Created attachment 19492 [details]
Output of dash-and-miter.c
Image output of dash-and-miter.c. The unexpected bit is the little square on top of the vertical bar.
This is the cause of the odd behaviour: (cairo-path-stroke::_cairo_stroker_line_to_dashed(), line ~931) /* This segment ends on a transition to dash_on, compute a new face * and add cap for the beginning of the next dash_on step. * * Note: this will create a degenerate cap if this is not the last line * in the path. Whether this behaviour is desirable or not is debatable. * On one side these degenerate caps can not be reproduced with * regular path stroking. * On the other side Acroread 7 also produces the degenerate caps. */ So the result is we insert a degenerate cap between the dashed segments. Time to extend the test... Created attachment 19500 [details]
Current behaviour for degenerate dashes
Created attachment 19501 [details]
PS behaviour
PostScript seems to have slightly saner behaviour.
Created attachment 28590 [details]
Quartz behaviour
Another argument against the behaviour of the image backend is animation of the stroked path.
If I were to stroke multiple times a dashed path changing only the dash offset, I would expect the dashes to simply move along the path without ever changing shape (including their caps) except for having an appropriate join when they get bent.
The PS backend already does this for round and butt caps, but apparently not for the square cap (I would expect the square-capped lines in "PS behaviour" to terminate with a single square, to be coherent with the round cap style).
The attachment should show what I would expect to be the correct output for the degenerate-dash test.
(On a side note, it's the output I'm getting from quartz after some work on fixing the dashes).
I'll try to post a code snippet to excercise dashing with joins/caps as soon as possible.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/119. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 19491 [details] Miter quad where it shouldn't be. The attached test case strokes a dashed line that turns a corner when the next dash is about to start. The output shows an extra rectangle in the upper right corner from a wrong miter join that shouldn't be there. The path being stroked is the top and right edges of a square, and the dash pattern is 50% on / 50% off for each edge. Expected: #### #### #### #### #### Got: #### ## <- huh? #### #### #### ####