[whatwg] Stroking algorithm in Canvas 2d

[Rik Cabanier]

Thanks for your feedback Justin!


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

>
>
>> On Thu, Oct 10, 2013 at 4:19 PM, Jasper St. Pierre <jstpierre at mecheye.net
>> > wrote:
>>
>>>
>>>  I can imagine an implementer assuming it's a direct translation of
>>> their underlying API.
>>>
>>
> As an implementer, I can speak to that. When I first laid eyes on the
> algorithm, I was expecting that assumption to hold, but there were a few
> hiccups.
>
> So far, there are a few differences between the spec and the graphics API
> I work with (skia) that attracted my attention:
> 1) the line caps on individual dashes: this is not yet resolved, and it is
> pretty far on my to do list (low volume of complaints)
>

Can you tell me what is wrong with line caps on dashes? Is that your
proposal to not have dashes on join and endcaps?


> 2) the way of handling dash sequences with an odd number of elements
> (concatenate the sequence onto itself to make it even): this was easy to
> resolve, although I have reservations about this. I think it may feel
> unnatural to many graphics designers.
>

Yes, that looked very odd to me too. Usually when you set an array, you get
the same array values back.
To bad that it already landed in 3 browsers...


> 3) The method of mapping the dash pattern to the path: I suspected this
> might be a problem, but I didn't really pay much attention to it until this
> thread started.
> 4) Inflating paths: this did not worry me at all. I was confident that any
> differences in results would be negligible and decided not to even
> investigate unless someone reported a bug.
>

True. It didn't really matter for now. However, if we allow getting the
stroke outlines in the future, we needed a better description how stroking
is done.
The current wording of "Sweeping a line" describes how you create a stroke
region and not an "inflated path".


>
>
>>> I'd like some canvas conformance tests for this behavior with proposed
>>> renders to help implementers.
>>>
>>
>>
> Yes, and again let me add an implementer's perspective. I do not intend to
> fully implement the algorithm that is in the spec, I only intend to
> integrate existing stroking algorithms that are provided by graphics APIs.
>  As Ian stated earlier, a formal textual description of the stroking
> process is important because of the normative nature of the specification.
> Understood. But having only that to work with is quite challenging because
> it means figuring out the gaps between the canvas spec and the graphics
> API's implementation, then finding ways map one to the other.  So far I
> have mostly (if not only) written tests for cases that I identified as
> issues needing to be resolved, I have not gone through the exercise of
> rigorously designing a series of tests that covers all the branches in the
> spec'ed algorithm and all the special cases, and combinations thereof. That
> would be useful, but it's a big chunk of work.
>
>
>>
>>>
>>>>
>>>
>>>
>>> --
>>>   Jasper
>>>
>>
>>
>