Re: [whatwg] Stroking algorithm in Canvas 2d

On Mon, Oct 28, 2013 at 11:05 AM, Justin Novosad <junov@google.com> wrote:

> If I understand correctly, the need to produce a path that is winding
> agnostic is for cases where we are not stroking to the display. It is for
> cases where the API produces a stored path that could be further
> manipulated.  The only examples of this that come to my mind right now are
> the addPathByStrokingPath and addPathByStrokingText methods of the Path
> object interface.  Is that what you had in mind?
>

Yes


> Perhaps the requirement for generating winding agnostic paths should be
> specific to those two methods?
>

Yes.
Right now, the spec says to take the output from "tracing a path" to those
APIs but it needs a postprocessing step to be useful (see *
outlined_stroke.png *from my previous message).
Most of my concern would go away if that is added.


>
> Also it may be helpful to provide an accurate/formal description of what
> winding agnostic means.  I think I have a good idea of what it means: line
> cross count is 0 or 1 at any given point. Correct?
>

Yes. Also, the orientation of paths is so that a line will find clockwise
to anti-clockwise paths.


>  I am sure these are solved problems and there must be plenty of
> literature on the subject, but it would be great to provide either
> algortihms or references to algorithms for converting paths that are meant
> to be filled with a given winding rule into a winding agnostic
> representation that produces the same result.
>

I'm unsure if there are papers on this subject. After removing path
segments that have color on each side, it's a simple operation.
Cary, do you know of any papers on making paths winding agnostic?



> On Mon, Oct 28, 2013 at 1:39 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>>
>>
>>
>> On Mon, Oct 28, 2013 at 7:04 AM, Justin Novosad <junov@google.com> wrote:
>>
>>>
>>> On Sun, Oct 27, 2013 at 10:36 PM, Rik Cabanier <cabanier@gmail.com>wrote:
>>>
>>>>  The outline should be done in such a way that it is not affected by
>>>> winding.
>>>>
>>>
>>> Why is that important? Enforcing that can add a lot of complexity to
>>> cases of self intersecting strokes, or line caps that overlap (
>>> http://jsfiddle.net/aBmZ4/2/).  Today, these problems are easy to solve
>>> correctly by using a non-zero fill.
>>>
>>
>> Hi Justin,
>>
>> this was for APIs that calculates the outline/path of a stroke. Regular
>> strokes can use nzo-fill (if they're implemented by drawing paths).
>> Being winding agnostic is more author friendly. Otherwise the author
>> would have to remember that the other winding would give bad results. I've
>> relied on this behavior of our path optimizer many times in the past.
>> Compared to how difficult it is to get a useful outlined stroke,
>> reversing paths is very easy.
>>
>> A "useful" stroke needs to remove subsections that have a color on both
>> sides.
>> I've attached an example outlined_stroke.png.
>> Example 1 is a dashed stroke where the endcaps overlap
>> Example 2 is the path that is calculated by the stroking algorithm and
>> filled with NZO
>>
>> Example 3 is the path that describes the region of the stroke and is what
>> would be useful for an author
>>
>>
>

Received on Monday, 28 October 2013 18:40:38 UTC