# [whatwg] Stroking algorithm in Canvas 2d

Ian Hickson ian at hixie.ch
Tue Oct 15 16:18:12 PDT 2013

```On Mon, 9 Sep 2013, Stephan Yhann wrote:
> > On Thu, 5 Sep 2013, Rik Cabanier wrote:
> > >
> > > we've looked over the algorithm in the Canvas spec that describes
> > > how strokes are computed. [1] We think that this section is making
> > > some incorrect assumptions. For instance, the dashes are calculated
> > > over the total lenght of all subpaths, but each subpath should be
> > > treated separately.
> >
> > That's intentional, otherwise if you stroke an already-dashed line,
> > you get weird results.
>
> Can you clarify what you mean by "an already-dashed line".  Do you mean
> a line that has been split in to shorter segments, each of dash length?
> If so, can you describe the weird results?

I mean that if you have a line that consists of a series of dashes, and
you want to stroke it with a dash pattern, you'll get ugly results if you
start again with each subpath. For example:

// http://goo.gl/rPN5Eg
c.setLineDash([3])
c.beginPath();
c.moveTo(100,100);
c.lineTo(120,100);
c.moveTo(130,100);
c.lineTo(150,100);
c.moveTo(160,100);
c.lineTo(180,100);
c.moveTo(190,100);
c.lineTo(210,100);
c.stroke();

You get something like:

-- -- -- -   -- -- -- -   -- -- -- -   -- -- -- -

-- -- -- -   - -- -- --    -- -- --    -- -- -- -

...which would look more balanced.

> Also, I did not see a reference to curves and how they should be
> handled.

Could you elaborate on what text in the spec you think doesn't handle
curved lines?

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

On Thu, 10 Oct 2013, Justin Novosad wrote:
> On Thu, Oct 10, 2013 at 4:20 PM, Rik Cabanier <cabanier at gmail.com>
> wrote:
> >
> > would you change Canvas' stroking behavior so it no longer matches SVG
> > [...] and your underlying graphics libraries?
>
> My first reflex is to say that of course it would be convenient for
> implementors and web developpers alike if dashes were consistent across
> all web standards. I don't feel super strongly about that though, and
> could easily be convinced otherwise. How much does that really matter to
> the Web?

On Thu, 10 Oct 2013, Stephan Yhann wrote:
>
> I am curious as to the motivation for creating a new dashing model
> instead of adopting an existing model that developers and designers are
> all familiar with. Is the new model addressing specific problems that
> the well know dashing model cannot solve.

Yes; it's addressing the problems that have been discussed in this thread
several times.

- the dash density is biased to the start of the pattern if you reset
with each subpath, which is aesthetically displeasing

- if the pattern resets at each subpath, then you can't take a dashed
path and then split it arbitrarily, moving subparts of the path,
without the pattern suddenly shifting when the path is "cut".

If we are going to have per-point control over this behaviour (as
suggested in the aforementioned bug), then I don't mind so much what the
default behaviour is.

> Introducing a new dashing model adds complexity to conversions from one
> graphics model to another, e.g., when printing a web page or saving it
> as PDF, converting from PDF to HTML or exporting to HTML from current
> WYSIWYG drawing/design programs.  For example, PDF and SVG both have an
> operator to stroke and fill a path.  Compound paths, (e.g. a donut with
> an inner and outer circle), that are both stroked and fill would need to
> be duplicated and broken up into two paths to be drawn correctly into
> this model - assuming they are created in an application/format that
> works with the PDF/SVG stroking model.
>
> Additionally, I think that having dashes continue across sub paths
> introduces uncertainty in the graphic design. Consider a designer
> editing a sub-path on a dashed path with multiple sub paths. Changing
> the length of one sub-path will affect the dashing on the other sub
> paths. This is really counter intuitive to what is expected. Also, I
> think that from a designers perspective it will be harder to create a
> desired look on compound paths (unless you like adding numbers as you
> work). I think the placement of the dash on start and end points of
> paths and sub paths is the critical design element and continuing
> dashing across sub paths defeats this.

These are good arguments for the reset behaviour. I don't see them as
particularly more or less compelling than the arguments above. If we are
going to eventually allow both behaviours, it's kind of moot; all that
matters then is the default.

> Finally, I think the join and other effects suggested as motivations for
> the new dashing model are higher level and should be styles settings or
> similar where the underlying implementation uses the basic stroking
> apparatus to achieve the desired look.

Not sure what this means.

On Thu, 10 Oct 2013, Rik Cabanier wrote:
> >
> > Here's my concrete use case. I have a dashed line. I want the user to
> > click two points on it, and then I want to split the line at those
> > points and move the three segements independently. I do not want the
> > dashes to change when I go from there being one line to there being
> > three.
> >
> > How do I get this effect with the mechanism you describe?
>
> You use dashOffset and stroke multiple times.

Why is that a sufficient answer for my case but not yours? It seems it
would apply equally well in both cases.

On Thu, 10 Oct 2013, Jasper St. Pierre wrote:
>
> Consistency with every other drawing model out there is probably more
> important than you first imagine. Documentation, testing,
> interoperability between browsers, and developer learning are all big
> motivations to keep things the same.

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?

> 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
> 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].

> 3) The method of mapping the dash pattern to the path: I suspected this
> might be a problem, but I didn't really pay much attention to it until this

This should now match the industry convention.

> 4) Inflating paths: this did not worry me at all. I was confident that any
> differences in results would be negligible and decided not to even
> investigate unless someone reported a bug.

As far as I can tell, the spec here is what you'd expect.

On Tue, 15 Oct 2013, Justin Novosad wrote:
> >>
> >> 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
> >> feel unnatural to many graphics designers.
> >
> > Yes, that looked very odd to me too. Usually when you set an array,
> > you get the same array values back. To bad that it already landed in 3
> > browsers...
>
> The Abilene paradox strikes again :-(

I don't think this is a cast of going to Abilene. At least, not for me. I
don't see what else would be better than what we have now, here.

On Fri, 11 Oct 2013, Smylers wrote:
>
> If a new web developer asks “Why isn't there a straightforward way of
> doing X?”, I'd rather that the answer isn't “To retain compatibility
> with a non-web technology which was invented before you were born.”

Agreed.

In this case, if we add a feature in the future to control this, it'll be
moot -- all the various behaviours will be possible.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
```