Re: [whatwg] Stroking algorithm in Canvas 2d

On Thu, Oct 10, 2013 at 1:28 PM, Ian Hickson <ian@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
gaps.


>
>
> > 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
> proposals.
>

setLineDash([30]);
rect(10, 10, 100, 100);
rect(10, 110, 100, 100);
rect(10, 210, 100, 100);
stroke();

 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)?
>
> 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.


ah. Yes, the new text is much better.
I think that works.

Received on Thursday, 10 October 2013 21:22:37 UTC