Re: [whatwg] Stroking algorithm in Canvas 2d

On Wed, Oct 9, 2013 at 11:19 PM, Ian Hickson <ian@hixie.ch> wrote:

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

I think in your mind, you put the path down and then the stroke follows
that path. It's as if you take one continuous stroked and dashed line, then
cut it in pieces and then drape over the path.

This is not how stroking works. Stroking works like a pen. Every moveTo is
where you lift up the pen and move it to a new location. curves and line
then tell the pen where to go.
Dashing starts over every time you lift up the pen and acts as if you lift
up the pen, move and put it down again.


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


I think you just have a different model in your head.
Think how an artist would outline a shape with a marker


> > They're not always lines though. What about curves?
>
> Curves are lines too. The spec uses the term "path", though.


We've touched on this before. Curves can't simply be offset and still be
bezier curves.
For instance, if you take the following snippet of SVG:

<path fill="none" stroke="#000000" stroke-miterlimit="10"
d="M50,150C50,50,82.908,42.906,150,62.886"/>

The outlined stroke will look like this:

<path d="M256.5,150h-1*c*0-47.957,7.732-76.057,24.333-88.435*c*18.433-13.744,47.57-7.718,76.31,0.841l-0.285,0.958
*c*-38.963-11.603-60.816-11.894-75.427-0.998*C*264.104,74.54,256.5,102.386,256.5,150z"/>



Note how there are now 2 beziers on each edge to approximate the stroke.

Received on Thursday, 10 October 2013 17:34:49 UTC