[cairo] Inconsistent close_path behavior
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
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
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060818/019e5f56/attachment.pgp
More information about the cairo