W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2015

Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 16 Nov 2015 11:16:55 -0800
Message-ID: <CAGN7qDBUGsc7CRkTz=qw3qS6ZfoW02zmGgo_rQi1rtQ+r2-3=Q@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: WHAT Working Group <whatwg@whatwg.org>
On Mon, Nov 16, 2015 at 10:54 AM, Justin Novosad <junov@google.com> wrote:

>
>
> On Mon, Nov 16, 2015 at 1:40 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>>
>>
>> On Mon, Nov 16, 2015 at 9:41 AM, Justin Novosad <junov@google.com> wrote:
>>
>>> Also, the part about "repeating the last (possibly implied) moveTo()
>>> call" doesn't make much sense if we assume that closePath() applies to the
>>> new sub path that was started by the last moveTo() call.
>>>
>>
>> It *is* super confusing. I complained about this in the past but it
>> didn't go anywhere.
>>
>
>> For the implied moveTo case, take the following code::
>>
>> ctx.lineTo(0,0); // no moveTo, so moveTo(0,0) is implied -> create new
>> subpath with points (0,0), (0,0)
>> ctx.lineTo(100,100); -> subpath (0,0), (0,0), (100,100)
>> ctx.closePath(); // draw line to (0,0) -> subpath (0,0), (0,0),
>> (100,100), (0,0) then create new subpath with point (0,0)
>> ctx.stroke();
>>
>>
> To be clear, my problem with the wording is that "(possibly implied)"
> implies that the moveTo may also be explicit. In the case where there is an
> explicit (non-implied) moveTo, does that make closePath essentially a no-op?
>

Can you write out the calls so it's clear if we're talking about the
current or previous subpath?


> On Mon, Nov 16, 2015 at 12:38 PM, Justin Novosad <junov@google.com> wrote:
>>>
>>>> That makes sense, but the text for closePath() talks about "the last
>>>> subpath", which I guess is a bit unclear.
>>>>
>>>> On Mon, Nov 16, 2015 at 12:30 PM, Rik Cabanier <cabanier@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad <junov@google.com>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> The text in the spec:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>> The closePath() method must do nothing if the object's path has no
>>>>>> subpaths. Otherwise, it must mark the last subpath as closed, create
>>>>>> a new
>>>>>> subpath whose first point is the same as the previous subpath's first
>>>>>> point, and finally add this new subpath to the path.
>>>>>>
>>>>>> Note: If the last subpath had more than one point in its list of
>>>>>> points,
>>>>>> then this is equivalent to adding a straight line connecting the last
>>>>>> point
>>>>>> back to the first point, thus "closing" the shape, and then repeating
>>>>>> the
>>>>>> last (possibly implied) moveTo() call.
>>>>>>
>>>>>> </snip>
>>>>>>
>>>>>> Problematic use case:
>>>>>>
>>>>>> ctx.moveTo(9.8255,71.1829);
>>>>>> ctx.lineTo(103,25);
>>>>>> ctx.lineTo(118,25);
>>>>>> ctx.moveTo(9.8255,71.1829);
>>>>>> ctx.closePath();
>>>>>> ctx.stroke();
>>>>>>
>>>>>> Should this draw a closed triangle or two connected line segments?
>>>>>> According to the "Note" (or at least my interpretation of it), this
>>>>>> should
>>>>>> draw a closed triangle. But it appears that this is not what many
>>>>>> browsers
>>>>>> have implemented.  Chrome recently became compliant (or what I think
>>>>>> is
>>>>>> compliant), and the change in behavior was reported as a regression.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>
>>>>> moveTo creates a new subpath. This means the closePath is going to do
>>>>> nothing because the subpath is empty.
>>>>> So according to the spec, this should create 2 connected lines.
>>>>>
>>>>
>>>>
>>>
>>
>
Received on Monday, 16 November 2015 19:17:27 UTC

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