[whatwg] Stroking algorithm in Canvas 2d

[Rik Cabanier]

On Thu, Oct 10, 2013 at 2:48 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 10 Oct 2013, Rik Cabanier wrote:
> > 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?
>
> Do you have URLs I could look at?
>
>
> > > 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?
>
> Presumably because it's not a continuous path. For example, it might be a
> stick figure with two arms and two legs and a head. It's not clear how you
> would draw that as one continuous path.
>
>
> > That is not guarenteed to look the same anyway since if you have curves,
> > you will get gaps.
>
> Not guaranteed to look the same as what? I'm not sure anyone is asking for
> anything to look the same as something else.
>
>
> > > 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)
>
> Here's my concrete use case. I have a dashed line. I want the user to
> click two points on it, and then I want to split the line at those points
> and move the three segements independently. I do not want the dashes to
> change when I go from there being one line to there being three.
>
> How do I get this effect with the mechanism you describe?
>

You use dashOffset and stroke multiple times.


>
>
> > setLineDash([30]);
> > rect(10, 10, 100, 100);
> > rect(10, 110, 100, 100);
> > rect(10, 210, 100, 100);
> > stroke();
> >
> > These rectangles should look the same.
>
> I presume you mean "I want those rectangles to look the same". I don't see
> any a priori objective reason why they should look the same.
>
> You could get that effect easily with my proposal:
>
>  setLineDash([30]);
>  beginPath();
>  rect(10, 10, 100, 100);
>  stroke();
>  beginPath();
>  rect(10, 110, 100, 100);
>  stroke();
>  beginPath();
>  rect(10, 210, 100, 100);
>  stroke();
>
>
> > > > 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.
>
> Sure. We can support these easily if we implement dashing as the spec says
> now, by just adding the feature Justin suggested: an annotation on the
> path that says to reset the dash offset.


I didn't see that proposal.
In Justin's first reply, he asked for a new feature (=aligning dashes) and
agreed that a moveTo should restart the dashes.