[whatwg] Stroking algorithm in Canvas 2d

[Rik Cabanier]

Looking at the current spec [1], I see that Ian updated how dashing is
calculated  (thanks!)

I still have a couple of questions:
1. Step 4:

Add a straight closing line to each closed subpath in path connecting the
last point and the first point of that subpath; change the last point to a
join (from the previously last line to the newly added closing line), and
change the first point to a join (from the newly added closing line to the
first line).

Is this needed? A closed subpath already drew a line [2]. Maybe it could be
simplified to:

If a subpath is marked as closed, replace all points with joins.


2. Calculating dashing is a bit strange
For instance, let's say with have a dash array of [5 5 3 3] with a dash
offset of 0 and apply it to a path of length 20.
According to the spec:
- pattern width = 16
- subpath width = 20
- offset = *16* (from step 3: "While offset is less than pattern width,
increment it by pattern width")
- position = *-16* (from step 5: "Let position be zero minus offset.")

If you follow the steps, you have to go through the loop twice before
drawing starts.
Maybe we can change step 3:

While offset is greater than pattern width, decrement it by pattern width.
While offset is less than *zero*, increment it by pattern width.


3. Step 20:

If position is greater than width, then jump to the step labeled convert.

I think that should be:

 If position is greater than *subpath *width, then jump to the step labeled
convert.



1:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path
2:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-closepath



On Sun, Oct 27, 2013 at 7:36 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> Can we pick this up again?
>
> I think we should update the algorithm [1] so the problem is broken into
> stages:
> 1. For each subpath, use the dash array to break it into a smaller
> subpaths + remember the direction of the path (for 0 length dashes). The
> default will use 0 + the dashoffset of each subpath, a TBD option allows
> you to remember the phase were you left off. This left-off phase is added
> when starting the next sub path
> 2. For each of the new subpaths, draw an area that is derived from
> sweeping a line across the direction of the path.
> 3. For each of the new subpaths, draw the end caps
> 4. For each of the new subpaths, draw the line joins
>
> For each stage, we should also provide pictures.
>
> Deriving a path from a stroke is tricky, but I think we can say that it is
> derived by outlining the region of the stroke. The outline should be done
> in such a way that it is not affected by winding.
>
> 1:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path
>
>
> On Wed, Oct 16, 2013 at 6:58 AM, Justin Novosad <junov at google.com> wrote:
>
>> On Tue, Oct 15, 2013 at 7:18 PM, Ian Hickson <ian at hixie.ch> wrote:
>>
>> >
>> > On Thu, 10 Oct 2013, Rik Cabanier wrote:
>> > > On Thu, Oct 10, 2013 at 12:25 PM, Justin Novosad <junov at google.com>
>> > wrote:
>> > > >
>> > > > http://jsfiddle.net/ZxR6P/1/
>> > >
>> > > Yes, that looks like "Align dashes to corners and path ends"
>> >
>> > I've filed a bug for this:
>> >    https://www.w3.org/Bugs/Public/show_bug.cgi?id=23528
>> >
>> > This thread now is mainly about what the default should be.
>> >
>>
>> Great, thanks!
>>
>>
>> >
>> > Fair enough. I've changed the spec to reset at new subpaths.
>> >
>> >
>> > On Fri, 11 Oct 2013, Justin Novosad wrote:
>> > >
>> > > So far, there are a few differences between the spec and the graphics
>> > API I
>> > > work with (skia) that attracted my attention:
>> > > 1) the line caps on individual dashes: this is not yet resolved, and
>> it
>> > is
>> > > pretty far on my to do list (low volume of complaints)
>> >
>> > My understanding is that the specced behaviour here matches SVG, right?
>> >
>>
>> Yes the spec is fine in this respect, and it turns out that Blink is not
>> as
>> broken as I initially thought it was when I wrote that.
>>
>>
>> > > 2) the way of handling dash sequences with an odd number of elements
>> > > (concatenate the sequence onto itself to make it even): this was easy
>> to
>> > > resolve, although I have reservations about this. I think it may feel
>> > > unnatural to many graphics designers.
>> >
>> > What's the alternative? Implying a zero at the end? I don't have a
>> strong
>> > opinion on this, though it does seem more useful to treat [3] as [3,3]
>> > than as [3,0].
>> >
>>
>> No, I don't mean an implied zero. I meant that at every iteration over the
>> dash pattern, the pattern is inverted if it has an odd number of elements
>> (blanks become dashes and vice versa). This would render exactly the same
>> as what is currently in the spec, which is consistent with SVG.  The only
>> difference is that there is no doubling of the array.  If the array needs
>> to be doubled in order to work with the underlying graphics API, that
>> should be the UA's business and it should be hidden under the hood.
>>
>
>