[whatwg] Stroking algorithm in Canvas 2d

[Ian Hickson]

On Thu, 10 Oct 2013, Rik Cabanier wrote:
> > >
> > > If you draw a rect with dashes today, the dashing will be applied 
> > > normally. Justin wants to change this behavior so we will need 
> > > something to trigger that. Othewise, existing applications that use 
> > > dashed rectangles will start looking different.
> >
> > Do we really have enough deployed content using this API that we are 
> > already constrained? What applications are these?
> 
> Not sure I follow. Are you asking who would use dashed rectangles in 
> canvas?

You mentioned "existing applications". I'm just curious which these are?


> > > > It's not how stroking works in PDF, but there's no reason that I 
> > > > can see that it shouldn't be how stroking works.
> > >
> > > This is how stroking works *everywhere *including canvas today.
> >
> > There's three possible arguments for doing something:
> >
> >  - we have to because there's content depending on it, here is the
> >    data supporting that. (That data might be "the browser vendor
> >    refuses to implement anything else".)
> >
> >  - here are some logical reasons for doing it.
> >
> >  - here is evidence showing that authors want us to do it.
> >
> > So far I've heard "we have to do that because everyone else does 
> > that", which isn't any of those three possible arguments.
> 
> Well, your proposal doesn't do any of those 3 arguments either.

Apologies for not being clearer. I'm attempting to do the second: provide 
logical reason for the proposal.

Specifically: it allows for all three kinds of renderings. You can have 
the behaviour you're describing by creating new paths. You can have the 
behaviour I'm describing by using a single path. You can have the 
behaviour Justin described by a modest addition to the path API (as he 
described). This is better than the alternative because it's more 
flexible. Justin also pointed out some other arguments, specifically that 
not restarting at each subpath results in an overall more even 
distribution of the dash density, which is aethestically pleasing.


> For reason 1, I'm sure every browser would object as it doesn't follow 
> their model.

I'm sure browser vendors would not object purely on those grounds. 
However, maybe I'm wrong. We can only know if they actually do or do not 
object. (Justin did not seem to object, but maybe I misintepreted him.)


> For reason 2, it would be really funky that drawing 3 identical lines 
> (or rects or circles) would produce 3 different renditions.

It would be really funky that if you took a line:

   ---------------------------

...and then split it in three and moved the three parts around in an 
animated fashion:

   ---------
            ---------
                     ---------

...the dash pattern would change.

So "funkyness" isn't a compelling argument: it can be used to defend both 
proposals.


> For reason 3, authors will be surprised that identical constructs from 
> SVG, Core Graphics or their drawing applications would look different in 
> Canvas.

I think most authors of Web applications have never used those APIs. Where 
is the data demonstrating this one way or the other?


> > > We can't change the current implementations anyway because they are 
> > > already used.
> >
> > If that's true, it trumps all other arguments, and we shouldn't be 
> > trying to have other arguments. Where's the data showing this?
> 
> Data that people are using dashing (which has been shipping in WebKit 
> for the last year)?

Right.


> The spec still says:
> 
> Create a new path that describes the result of inflating the paths in 
> path perpendicular to the direction of the path to the styles lineWidth 
> width, replacing each point with the end cap necessary to satisfy the 
> styles lineCap attribute as described previously and elaborated below, 
> and replacing each join with the join necessary to satisfy the styles 
> lineJoin type, as defined below.

Looks like the multipage version got out of sync. Should be fixed now.

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