Re: [whatwg] Stroking algorithm in Canvas 2d

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

Received on Thursday, 10 October 2013 06:19:24 UTC