[whatwg] Stroking algorithm in Canvas 2d

[Rik Cabanier]

On Fri, Sep 6, 2013 at 7:11 AM, Justin Novosad <junov at google.com> wrote:

>
>
>
> On Thu, Sep 5, 2013 at 11:48 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> All,
>>
>> we've looked over the algorithm in the Canvas spec that describes how
>> strokes are computed. [1]
>> We think that this section is making some incorrect assumptions. For
>> instance, the dashes are calculated over the total lenght of all subpaths,
>> but each subpath should be treated separately.
>>
>
> Why? Don't we want there to be continuity in the dash pattern across
> joins? Especially considering that step 3 of the algorithm breaks all
> subpaths into elementary line segment subpaths.  Or am I misunderstanding
> your comment?
>

Maybe. The spec currently says:


   1.

   Let width be the aggregate length of all the lines of all the subpaths
   in path, in coordinate space units.

For dashing, each subpath should be treated separately. There shouldn't be
a step that takes the total length of all subpaths.

You are correct that dashing should result in a new series of subpaths that
are then stroked (with joins and endcaps) usual.


>
>> It's also a bit strange that the spec is trying to describe how to stroke.
>> For instance, it goes in minute detail on how dashes are applied but the
>> hardest part of stroking ("inflating the paths in path perpendicular to
>> the
>> direction") is not described at all. Wouldn't it be better to remove all
>> these steps and simply show the desired effect?
>>
>
> I agree.  I think it would be clearer if the spec focused on what the
> expected output is.  I see the current algorithm-based specification as
> unnecessarily challenging for implementors and web developers alike. The
> challenge for implementors is that this algorithm in unlikely to be
> implemented exactly as is since implementors will want to leverage
> services, respect constraints, and consider performance characteristics of
> the graphics APIs they are using.  In other words, implementors are likely
> to have to figure-out alternate algorithms that produce equivalent results,
> which means they have to start by reverse-engineering the spec in order to
> figure-out what the desired output is. Reverse-engineering the spec is also
> necessary just for writing conformance tests. The algorithm in itself is
> still very useful as an example of how the spec could be implemented.
>
> FWIW, In general I have no issue with other parts of the spec that are
> specified as algorithms. It is just this one that I find particularly
> unwieldy.
>
> If not, what would be the best way to fix the wording? The mailing list or
>> a bug?
>>
>> 1:
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path
>>
>
>