[whatwg] Stroking algorithm in Canvas 2d
Ian Hickson
ian at hixie.ch
Wed Oct 9 23:19:00 PDT 2013
On Wed, 9 Oct 2013, Rik Cabanier wrote:
> > >
> > > Yep, this is where assumptions went wrong. Dashes are calculated per
> > > subpath, not per 'line'/whole path.
> >
> > On what basis are you asserting this?
>
> see this fiddle: http://jsfiddle.net/6eGxU/25/
This demonstrates pretty well what is wrong with the algorithm you're
suggesting (and which is implemented in Chrome). Why shouldn't we take
this opportunity to fix it?
Here's an even better example of the problem:
http://goo.gl/hwK7fv
It doesn't make any sense, as far as I can tell, that the lines in the
discontinuous box would have different gaps than the line in the
continuous box. They're the same lines. Only the joins should be
different. Why would we do this?
(Note that in most cases you can simulate the effect of restarting with
each subpath pretty easily by just painting the subpaths separately,
instead of as one single path. I don't see any good way to simulate the
way it's specced with the model you describe.)
> I think most (all?) graphics libraries traces their root back to
> PostScript. PDF, Core Graphics, Cairo and Direct2D all follow the same
> algorithm.
If there's a good reason to do this, other than "we've always done it this
way", then it's certainly a good thing to consider. If none of the
browsers are willing to implement it the way the spec describes it, that's
also a reason to change the spec. But just that it's always been done that
way isn't a reason at all.
> They're not always lines though. What about curves?
Curves are lines too. The spec uses the term "path", though.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list