Re: [whatwg] Stroking algorithm in Canvas 2d

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@google.com> wrote:

> On Tue, Oct 15, 2013 at 7:18 PM, Ian Hickson <ian@hixie.ch> wrote:
>
> >
> > On Thu, 10 Oct 2013, Rik Cabanier wrote:
> > > On Thu, Oct 10, 2013 at 12:25 PM, Justin Novosad <junov@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.
>

Received on Monday, 28 October 2013 02:37:20 UTC