W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Stroking algorithm in Canvas 2d

From: Justin Novosad <junov@google.com>
Date: Fri, 11 Oct 2013 09:17:50 -0400
Message-ID: <CABpaAqQcZN1FXbY1u00EENOb4jx89+LpKnj4Yg2yMYVJXqYxbg@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: Ian Hickson <ian@hixie.ch>, "Jasper St. Pierre" <jstpierre@mecheye.net>, syhann@adobe.com, "whatwg@whatwg.org" <whatwg@whatwg.org>
>
> On Thu, Oct 10, 2013 at 4:19 PM, Jasper St. Pierre <jstpierre@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)
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.
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.


>> 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
>>
>
>
Received on Friday, 11 October 2013 13:18:18 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:11 UTC