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

Re: [whatwg] Stroking algorithm in Canvas 2d

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 14 Oct 2013 10:54:04 -0700
Message-ID: <CAGN7qDDpW2_U_XV8AcLVgj906wGq6d14gZAaOH7ZE4ZRZndvMw@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: Ian Hickson <ian@hixie.ch>, "Jasper St. Pierre" <jstpierre@mecheye.net>, syhann@adobe.com, "whatwg@whatwg.org" <whatwg@whatwg.org>
Thanks for your feedback Justin!

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

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

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
Received on Monday, 14 October 2013 17:54:29 UTC

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