Re: [whatwg] Stroking algorithm in Canvas 2d

On Tue, Oct 15, 2013 at 4:18 PM, Ian Hickson <ian@hixie.ch> wrote:

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


That's debatable :-)
To me, the first one looks 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?


I think that was addressed with your changes that describe that a stroke is
like sweeping a line.


> 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.
>
>
> On Thu, 10 Oct 2013, Justin Novosad wrote:
> > On Thu, Oct 10, 2013 at 4:20 PM, Rik Cabanier <cabanier@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.


Well, I believe that the default should be what all graphical libraries
have implemented and what is expected by graphical applications and most
authors.
We can provide an optional argument to implement your proposal.


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


I think he means that dashing happens first and basically chops up the path
in sections. Those sections are then treated as normal subpaths (except we
have to special case zero length segments since they need to align to the
direction of the path)


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


Sure. I thought at this point we were debating how we could get your
behavior with the existing model.


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


SVG doesn't define anything wrt dashing. They just list the parameter.
I'm unsure what's missing for line caps but we should call out what happens
to 0 length dash patterns [0 2]


> > 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, just return [3] as what was passed in.


>
>
> > 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.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Wednesday, 16 October 2013 03:37:29 UTC