[whatwg] Stroking algorithm in Canvas 2d
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.  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:
You get something like:
-- -- -- - -- -- -- - -- -- -- - -- -- -- -
-- -- -- - - -- -- -- -- -- -- -- -- -- -
...which would look more balanced.
> Also, I did not see a reference to curves and how they should be
Could you elaborate on what text in the spec you think doesn't handle
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:
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>
> > 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
- 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  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.”
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg