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

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

From: Justin Novosad <junov@google.com>
Date: Mon, 16 Nov 2015 14:52:44 -0500
Message-ID: <CABpaAqQ6f571595sasYnOmdQR=MoBwsBFTBRCGa4uMnOOoq88g@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: WHAT Working Group <whatwg@whatwg.org>
On Mon, Nov 16, 2015 at 2:16 PM, Rik Cabanier <cabanier@gmail.com> wrote:

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

I am referring to the example I started this thread with:
ctx.moveTo(9.8255,71.1829);
ctx.lineTo(103,25);
ctx.lineTo(118,25);
ctx.moveTo(9.8255,71.1829);
ctx.closePath();
ctx.stroke();


>
>
>> 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:53:14 UTC

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