[cairo] [RFC] cairo_stroke_to_path implementation

[Andrea Canciani]

On Tue, Feb 2, 2010 at 3:23 AM, Jeff Muizelaar <jeff at infidigm.net> wrote:
> On 01/02/10 7:33 AM, Andrea Canciani 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.
>>
>
> I have this set up. However I only ever ran the stroke, spline, dash test
> cases.
I'm not sure if you received my second e-mail
(http://lists.cairographics.org/archives/cairo/2010-February/019069.html)
I ran stroke-to-path on the whole test suite and I'm seeing some
regressions (degenerate-arc and most *twin* tests (look at the "i"
glyph)) as you can see here:
http://people.freedesktop.org/~ranma42/test-stroke-to-path/
>>
>> I started reading the code (mainly comments) and I noticed that you
>> chose to flatten before doing stroke-to-path for dashed styles as no
>> easy way to split the bezier curve at a given length came to you. On
>> Graphics Gems V you can find a chpter about "The Length of Bezier
>> Curves". It allows to get upper and lower bounds for a bezier curve,
>> thus could be combined with bisection to find the value of the
>> parameter t at which the curve should be split (when t is known,
>> splitting the curve is just a straightforward application of de
>> casteljau).
>>
>
> Yeah, I considered this approach but was worried about performance. I'm
> still interested in future exploration in this area.
I think it should be possible to get the expected result without big
performance penalties. Basically instead of splitting the bezier at
the beginning we simply split it later.
I'll try to work out the details of bezier length-based splitting so
we'll be able to test it.
> For what it's worth, Skia has dasher that splits beziers at a given length
> so it might be worth investigating the technique used
> there too.
In the Skia codebase I found a bezier clipper (cutting a bezier to a
given coordinate), but no code splitting beziers at given length. It
looks like the dash code flattens curved paths.
>>
>> Moreover you missed quite a lot of opportunities to use some of the
>> functions you defined (in particular you often explicitly compute the
>> length of a vector_t and then normalize).
>> As I'll go on to reading the code I'll try to remove some of this code
>> duplication.
>>
>
> Patches welcome :)