[cairo] Inconsistent close_path behavior in cairo_path_copy_flat/cairo_stroke

Carl Worth cworth at cworth.org
Fri Aug 18 06:47:14 PDT 2006

On Wed, 16 Aug 2006 16:46:08 -0500, T Rowley wrote:
> _cpdp_close_path (used by cairo_path_copy_flat) behaves differently than
>   normal stroking.

Thank you so much for the report and the test case. The reproduction
recipe was very specific here, (close_path;curve_to along with

I wrote my own test case (close-path) for this bug, (one that would
fill the incorrect result via: copy_path_flat;append_path;fill). I
also added to that test case another test for a very similar-behaving
bug that I introduced the first time I tried to fix the above.

So there were some subtle issues here which made it quite a bit of fun
to chase down.

Interestingly enough, the fix I used did not involve adding improved
handling of current_point inside of _cpdp_close_path. On the contrary,
now none of the close_path functions change current point directly.

Instead, a call to cairo_close_path will now insert an explicit
move_to into the path immediately after the close_path. This makes the
path much more sane, since previously we had a funny state where after
a close_path there was a defined "current point" but never a move_to
to take the path to that point.

This change is user-visible since when using one of the
cairo_copy_path functions, one will now see this new MOVE_TO element
just behind the CLOSE_PATH elements. I can't imagine this will break
any existing code though, (I sure hope not).

I did update the documentation of cairo_close_path to describe the new
behavior as follows (the remainder of the close_path semantics are

 * Note: As of cairo version 1.2.4 any call to cairo_close_path will
 * place an explicit MOVE_TO element into the path immediately after
 * the CLOSE_PATH element, (which can be seen in cairo_copy_path() for
 * example). This can simplify path processing in some cases as it may
 * not be necessary to save the "last move_to point" during processing
 * as the MOVE_TO immediately after the CLOSE_PATH will provide that
 * point.

The changes I made can be seen as 4 patches here:


(Hmmm... that's not really a useful URL since it will always point to
the latest commits. I can generate a URL for a single commit as


but what I really want is a summary view with the history of several
commits (as in the first URL), but beginning with commit mentioned in
the second URL. Sounds like time to request another gitweb

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060818/019e5f56/attachment.pgp

More information about the cairo mailing list