[whatwg] Stroking algorithm in Canvas 2d
cabanier at gmail.com
Mon Oct 28 15:10:04 PDT 2013
Looking at the current spec , I see that Ian updated how dashing is
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
Is this needed? A closed subpath already drew a line . Maybe it could be
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
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
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  so the problem is broken into
> 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.
> 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
>> > 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
>> 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
>> > > 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
>> > opinion on this, though it does seem more useful to treat  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.
More information about the whatwg