[whatwg] Stroking algorithm in Canvas 2d
cabanier at gmail.com
Thu Oct 10 14:22:12 PDT 2013
On Thu, Oct 10, 2013 at 1:28 PM, Ian Hickson <ian at hixie.ch> wrote:
> 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?
Websites using canvas?
> > > > 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.
Why are you breaking a path up in sections in the first place? That is not
guarenteed to look the same anyway since if you have curves, you will get
> > 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.
Those are 3 lines; they are no longer 1 segment. (model of stroking =
drawing with a pen)
> So "funkyness" isn't a compelling argument: it can be used to defend both
rect(10, 10, 100, 100);
rect(10, 110, 100, 100);
rect(10, 210, 100, 100);
These rectangles should look the same.
> > 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?
I've seen several applications that morph SVG data into Canvas. Adobe has
tools that create canvas drawing calls to do stroking.
Mozilla's shumway and pdf.js rely on this as well.
> > > > 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)?
> > 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.
ah. Yes, the new text is much better.
I think that works.
More information about the whatwg