[whatwg] Stroking algorithm in Canvas 2d

[Ian Hickson]

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:

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

...instead of:

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

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

This thread now is mainly about what the default should be.


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


> 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
> thread started.

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 
> >> to resolve, although I have reservations about this. I think it may 
> >> 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.   `._.-(,_..'--(,_..'`-.;.'