[whatwg] Stroking algorithm in Canvas 2d

[Rik Cabanier]

On Thu, Oct 10, 2013 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 10 Oct 2013, Justin Novosad wrote:
> > On Thu, Oct 10, 2013 at 5:48 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > On Thu, 10 Oct 2013, Rik Cabanier wrote:
> > > >
> > > > setLineDash([30]);
> > > > rect(10, 10, 100, 100);
> > > > rect(10, 110, 100, 100);
> > > > rect(10, 210, 100, 100);
> > > > stroke();
> > > >
> > > > These rectangles should look the same.
> > >
> > > I presume you mean "I want those rectangles to look the same". I don't
> > > see any a priori objective reason why they should look the same.
> >
> > And is there an a priori objective reason why they should look
> > different? It seem pretty obvious to me that there would be way more
> > designers wanting the rects to look the same than there would be wanting
> > the rects to look different.
> >
> > [...] should we not provide the most desirable behavior by default?
>
> We should definitely provide the most desirable behaviour by default. The
> question is, what is it? The only argument one way or the other I've seen
> on this so far is the idea that if we don't reset, we get a more balanced
> distribution of the dash density, whereas if we do reset, the dash density
> is biased towards the start of the dash pattern.
>
> The actual most desireable behaviour may in fact be neither Rik's proposal
> nor mine, but something more like yours, where we somehow balance the
> dashes between each node in the path, but I don't really know exactly how
> to do that.
>

I think we should have that as an option. Doing it for rects is
straightforward, but I suspect that it might be more difficult for
arbitrary shapes.


> Just so we're clear, I really don't have a strong opinion on this issue. I
> just want to make sure we apply the same rigour to deciding what the model
> should be as we do to everything else, and that means not just doing
> things because they've always been done that way, but instead either
> figuring out why they've always been done that way, or starting from first
> principles or data and deriving the right behaviour.
>

I think that's totally reasonable. "That's how we've always done it" often
no longer applies.


>
> So far, the proposals seem to be to reset on each subpath, to not reset on
> each subpath, and to add more features to the API.
>
> If we don't want to add more features (features are expensive), then we're
> left with reset and not reset. You can do everything you can do with
> resetting in the no-resetting case; you can't do everything you can do
> without resetting in the reset case. So the only strong argument there is
> that one of the two ways provides more power to authors.


dashOffset is there for authors who want to implement the behavior you are
looking for.
They would have to calculate the length of the previous sub paths. As
Stephan and Justin have pointed out, the current implemented behavior is
less surprising to authors.