[whatwg] Stroking algorithm in Canvas 2d
cabanier at gmail.com
Thu Oct 10 13:07:04 PDT 2013
On Thu, Oct 10, 2013 at 12:44 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 10 Oct 2013, Rik Cabanier wrote:
> > > On Thu, 10 Oct 2013, Rik Cabanier wrote:
> > > > >
> > > > > One way we could address this by adding a new path method that
> > > > > inserts a break in the dashing pattern (without unjoining the
> > > > > subpaths). Also, I think it should be implicit in the rect() path
> > > > > primitive that the corners are joined and that they are also
> > > > > stop/start points for the dashing pattern.
> > > >
> > > > That would break current behavior . We will need a new API or
> > > > additional arguments (a dash array?)
> > >
> > > Can you elaborate? What would break?
> > 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?
> > > 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.
For reason 1, I'm sure every browser would object as it doesn't follow
For reason 2, it would be really funky that drawing 3 identical lines (or
rects or circles) would produce 3 different renditions.
For reason 3, authors will be surprised that identical constructs from SVG,
Core Graphics or their drawing applications would look different in Canvas.
> > 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)?
> > > Why is approximating a problem? It's not like we're doing pure math
> > > paths here, they're all approximated at the end of the day. The spec
> > > doesn't specify how you implement it exactly, it just requires that we
> > > have consistent results that, within the limitations of the hardware
> > > (e.g. only 1 pixel for every 10 microns) are indistinguishable from
> > > the theoretical results.
> > this is why drawings/pictures of what the stroke should look like are
> > more important.
> You can't write normative specifications with sample drawings. Or at
> least, if you can, I certainly haven't seen it done before. Spec by
> example is not the level of quality that we expect at the WHATWG.
Well, as I said, I've never seen this written out in prose before for
We can certainly do it if you think it's needed.
> > Saying "inflate the path perpendicular" is not good enough since it
> > could mean anything.
> That's why the spec no longer says that, as noted in my e-mail from
> > You either write out the math (which no spec has done afaik) or you give
> > examples (like
> > )
> Or you can give prose that describes it unambiguously, which I believe is
> what the spec does now.
The spec still says:
Create a new path<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#concept-path>
describes the result of inflating the paths in path perpendicular to the
direction of the path to the styles
replacing each point with the end cap necessary to satisfy the styles
as described previously and elaborated below, and replacing each join with
the join necessary to satisfy the styles
as defined below.
More information about the whatwg