[cairo] Fwd: cairo path rendering bug with inkscape

Carl Worth cworth at cworth.org
Sun Apr 6 00:03:37 PDT 2008

On Sat, 05 Apr 2008 23:27:52 -0700, Carl Worth wrote:
> For your optimization you would actually want the other half of
> move_to. That is, what you want to do is to change the current point,
> but without starting a new sub-path. I suppose we could add another
> function for that, but I wonder if it would be more confusing than
> helpful in general.
> In the meantime, you can actually do the right thing, but it takes a
> little more effort.

By the way, the extra effort for the optimization is only necessary if
the current sub-path will end in a close_path, (that is if in the path
data there is a "z" before the next "m" or "M"). From the looks of it,
the path representation that inkscape's working with knows this in
advance, (the last moveto was either MOVE_TO or MOVE_TO_CLOSED and
there's a 'closed' flag set in advance).

So, given that, the current optimization works just fine if the
current subpath will not be closed. It's what's already coded and it's
even more optimal[*] than my approach. So whether my idea gets coded
up or not, it might be nice to do the current thing whenever the
current path is not closed.


[*] The current approach is more optimal since it replaces each
line_to or curve_to with a move_to, hence no drawing at all. Instead,
the best mine can do is to replace a series of line_to or curve_to
operations with a single line_to. So if only a single operation gets
optimized, then there's not much savings, (and in the case of a single
line_to, no savings at all).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080406/7b493b39/attachment.pgp 

More information about the cairo mailing list