[whatwg] Stroking algorithm in Canvas 2d

[Rik Cabanier]

Ian,

at this point, should I file a bug on the dashing algorithm, or is the
email thread enough?


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.
>
>
> 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.
>
> 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.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>