[cairo] [RFC] cairo_stroke_to_path implementation

[Andrea Canciani]

On Mon, Feb 1, 2010 at 1:55 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Mon, 1 Feb 2010 13:33:48 +0100, Andrea Canciani <ranma42 at gmail.com> wrote:
>> On Fri, Jan 29, 2010 at 7:16 AM, Jeff Muizelaar <jeff at infidigm.net> wrote:
>> > Here's my current stroke-to-path work. Algorithmically it's basically where
>> > I want it to be, however it's still a bit messy, especially
>> > cairo-stroke-to-path.c. I welcome any comments about what needs to be done,
>> > stylistically and otherwise, before we can add commit this.
>> I put it on a branch on git
>> (http://cgit.freedesktop.org/~ranma42/cairo/?h=wip/stroke-to-path) to
>> make it easier to read it.
>> I think it would be quite interesting to check the stroke-to-path
>> behaviour by using it to "emulate" stroking on the test suite as it
>> would be used on many degenerate cases and a few complex ones. If
>> nobody has tried this yet, I'll do it asap and post the results.
http://people.freedesktop.org/~ranma42/test-stroke-to-path/
>
> You'll note how trivial it is to write a new stroke-to-polygon that can be
> used in place of the current one to enable this path. The changes I had to
> make last time were to eliminate all the mallocs and to apply tolerance.
> (I think the latter Jeff addressed at some point, but it's wise to check.)
I cheated and just used the path-to-polygon that was defined for the
fill operation.
> By making those changes, there were a number of visual differences between
> the reference image and stroke-to-path, but I favoured the output from
> stroke-to-path. (Even more so when you actually compare the polygons
> produced by both methods.) And also for real-world applications I measured
> a performance improvement (due to fewer edges and fewer intersections) -
> but the micro-benchmarks highlight the extra work done by stroke-to-path.
I patched a crash in the testsuite (the code is on my
wip/stroke-to-path branch) but there is another one not fixed yet
(new-sub-path).
(Yes, I know that my patch should be improved as it allocates an
unneeded object on the stack, but I wanted to keep the change small an
simple to understand).
The other failures are mainly caused by small differences (and often
they're pleasant, as you said), but there are a few true regressions
(degenerate-arc and most *twin* tests (look at the "i" glyph))
More patches soon ;)
Andrea Canciani