W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Stroking algorithm in Canvas 2d

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 10 Oct 2013 22:36:53 +0000 (UTC)
To: Justin Novosad <junov@google.com>
Message-ID: <alpine.DEB.2.00.1310102230220.11763@ps20323.dreamhostps.com>
Cc: "Jasper St. Pierre" <jstpierre@mecheye.net>, "whatwg@whatwg.org" <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>, syhann@adobe.com
On Thu, 10 Oct 2013, Justin Novosad wrote:
> On Thu, Oct 10, 2013 at 5:48 PM, Ian Hickson <ian@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.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 10 October 2013 22:37:18 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:11 UTC