[whatwg] Stroking algorithm in Canvas 2d

[Rik Cabanier]

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
their model.
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
stroking.
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
> yesterday.
>
>
> > You either write out the math (which no spec has done afaik) or you give
> > examples (like
> >
> https://developer.apple.com/library/ios/documentation/graphicsimaging/conceptual/drawingwithquartz2d/dq_paths/dq_paths.html
> > )
>
> 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>
that
describes the result of inflating the paths in path perpendicular to the
direction of the path to the styles
lineWidth<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-linewidth>
width,
replacing each point with the end cap necessary to satisfy the styles
lineCap<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-linecap>
attribute
as described previously and elaborated below, and replacing each join with
the join necessary to satisfy the styles
lineJoin<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-linejoin>
type,
as defined below.