Bug 17973 - Miter artifact for dashed strokes.
Summary: Miter artifact for dashed strokes.
Alias: None
Product: cairo
Classification: Unclassified
Component: general (show other bugs)
Version: 1.8.1
Hardware: Other All
: medium normal
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
Depends on:
Reported: 2008-10-08 06:59 UTC by M Joonas Pihlaja
Modified: 2018-08-25 13:39 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Miter quad where it shouldn't be. (923 bytes, text/x-csrc)
2008-10-08 06:59 UTC, M Joonas Pihlaja
Output of dash-and-miter.c (234 bytes, image/png)
2008-10-08 07:01 UTC, M Joonas Pihlaja
Current behaviour for degenerate dashes (1.97 KB, image/png)
2008-10-08 10:58 UTC, Chris Wilson
PS behaviour (1.89 KB, image/png)
2008-10-08 11:04 UTC, Chris Wilson
Quartz behaviour (1.76 KB, image/png)
2009-08-13 05:55 UTC, Andrea Canciani

Description M Joonas Pihlaja 2008-10-08 06:59:25 UTC
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.


####      ####


####        ## <- huh?
####      ####
Comment 1 M Joonas Pihlaja 2008-10-08 07:01:15 UTC
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.
Comment 2 Chris Wilson 2008-10-08 10:33:51 UTC
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...
Comment 3 Chris Wilson 2008-10-08 10:58:30 UTC
Created attachment 19500 [details]
Current behaviour for degenerate dashes
Comment 4 Chris Wilson 2008-10-08 11:04:24 UTC
Created attachment 19501 [details]
PS behaviour

PostScript seems to have slightly saner behaviour.
Comment 5 Andrea Canciani 2009-08-13 05:55:55 UTC
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.
Comment 6 GitLab Migration User 2018-08-25 13:39:18 UTC
-- 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.