Re: [whatwg] Stroking algorithm in Canvas 2d

Ian,

what do you think?
Does the spec need to be updated for stroking, or do you believe it is fine
as-is?


On Mon, Oct 28, 2013 at 3:10 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> Looking at the current spec [1], I see that Ian updated how dashing is
> calculated  (thanks!)
>
> I still have a couple of questions:
> 1. Step 4:
>
> Add a straight closing line to each closed subpath in path connecting the
> last point and the first point of that subpath; change the last point to a
> join (from the previously last line to the newly added closing line), and
> change the first point to a join (from the newly added closing line to the
> first line).
>
> Is this needed? A closed subpath already drew a line [2]. Maybe it could
> be simplified to:
>
> If a subpath is marked as closed, replace all points with joins.
>
>
> 2. Calculating dashing is a bit strange
> For instance, let's say with have a dash array of [5 5 3 3] with a dash
> offset of 0 and apply it to a path of length 20.
> According to the spec:
> - pattern width = 16
> - subpath width = 20
> - offset = *16* (from step 3: "While offset is less than pattern width,
> increment it by pattern width")
> - position = *-16* (from step 5: "Let position be zero minus offset.")
>
> If you follow the steps, you have to go through the loop twice before
> drawing starts.
> Maybe we can change step 3:
>
> While offset is greater than pattern width, decrement it by pattern width.
> While offset is less than *zero*, increment it by pattern width.
>
>
> 3. Step 20:
>
> If position is greater than width, then jump to the step labeled convert.
>
> I think that should be:
>
>  If position is greater than *subpath *width, then jump to the step
> labeled convert.
>
>
>
> 1:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path
> 2:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-closepath
>
>
>
> On Sun, Oct 27, 2013 at 7:36 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> Can we pick this up again?
>>
>> I think we should update the algorithm [1] so the problem is broken into
>> stages:
>> 1. For each subpath, use the dash array to break it into a smaller
>> subpaths + remember the direction of the path (for 0 length dashes). The
>> default will use 0 + the dashoffset of each subpath, a TBD option allows
>> you to remember the phase were you left off. This left-off phase is added
>> when starting the next sub path
>> 2. For each of the new subpaths, draw an area that is derived from
>> sweeping a line across the direction of the path.
>> 3. For each of the new subpaths, draw the end caps
>> 4. For each of the new subpaths, draw the line joins
>>
>> For each stage, we should also provide pictures.
>>
>> Deriving a path from a stroke is tricky, but I think we can say that it
>> is derived by outlining the region of the stroke. The outline should be
>> done in such a way that it is not affected by winding.
>>
>> 1:
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path
>>
>>
>> On Wed, Oct 16, 2013 at 6:58 AM, Justin Novosad <junov@google.com> wrote:
>>
>>> On Tue, Oct 15, 2013 at 7:18 PM, Ian Hickson <ian@hixie.ch> wrote:
>>>
>>> >
>>> > On Thu, 10 Oct 2013, Rik Cabanier wrote:
>>> > > On Thu, Oct 10, 2013 at 12:25 PM, Justin Novosad <junov@google.com>
>>> > wrote:
>>> > > >
>>> > > > http://jsfiddle.net/ZxR6P/1/
>>> > >
>>> > > Yes, that looks like "Align dashes to corners and path ends"
>>> >
>>> > I've filed a bug for this:
>>> >    https://www.w3.org/Bugs/Public/show_bug.cgi?id=23528
>>> >
>>> > This thread now is mainly about what the default should be.
>>> >
>>>
>>> Great, thanks!
>>>
>>>
>>> >
>>> > Fair enough. I've changed the spec to reset at new subpaths.
>>> >
>>> >
>>> > On Fri, 11 Oct 2013, Justin Novosad wrote:
>>> > >
>>> > > 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)
>>> >
>>> > My understanding is that the specced behaviour here matches SVG, right?
>>> >
>>>
>>> Yes the spec is fine in this respect, and it turns out that Blink is not
>>> as
>>> broken as I initially thought it was when I wrote that.
>>>
>>>
>>> > > 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.
>>> >
>>> > What's the alternative? Implying a zero at the end? I don't have a
>>> strong
>>> > opinion on this, though it does seem more useful to treat [3] as [3,3]
>>> > than as [3,0].
>>> >
>>>
>>> No, I don't mean an implied zero. I meant that at every iteration over
>>> the
>>> dash pattern, the pattern is inverted if it has an odd number of elements
>>> (blanks become dashes and vice versa). This would render exactly the same
>>> as what is currently in the spec, which is consistent with SVG.  The only
>>> difference is that there is no doubling of the array.  If the array needs
>>> to be doubled in order to work with the underlying graphics API, that
>>> should be the UA's business and it should be hidden under the hood.
>>>
>>
>>
>

Received on Sunday, 10 November 2013 01:39:29 UTC