Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()
On Mon, Nov 16, 2015 at 2:16 PM, Rik Cabanier wrote: > > > On Mon, Nov 16, 2015 at 10:54 AM, Justin Novosad wrote: > >> >> >> On Mon, Nov 16, 2015 at 1:40 PM, Rik Cabanier wrote: >> >>> >>> >>> On Mon, Nov 16, 2015 at 9:41 AM, Justin Novosad >>> 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 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 > wrote: > >> >> >> On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad >> wrote: >> >>> Hi All, >>> >>> The text in the spec: >>> >>> >>> >>> 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. >>> >>> >>> >>> 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. >> > > >>> >> >
Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()
On Mon, Nov 16, 2015 at 10:54 AM, Justin Novosad wrote: > > > On Mon, Nov 16, 2015 at 1:40 PM, Rik Cabanier wrote: > >> >> >> On Mon, Nov 16, 2015 at 9:41 AM, Justin Novosad 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 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 wrote: > > > On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad > wrote: > >> Hi All, >> >> The text in the spec: >> >> >> >> 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. >> >> >> >> 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. > >>> >> >
Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()
On Mon, Nov 16, 2015 at 1:40 PM, Rik Cabanier wrote: > > > On Mon, Nov 16, 2015 at 9:41 AM, Justin Novosad 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? > > > > >> On Mon, Nov 16, 2015 at 12:38 PM, Justin Novosad >> 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 >>> wrote: >>> On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad wrote: > Hi All, > > The text in the spec: > > > > 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. > > > > 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. >>> >>> >> >
Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()
On Mon, Nov 16, 2015 at 9:41 AM, Justin Novosad 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(); > On Mon, Nov 16, 2015 at 12:38 PM, Justin Novosad 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 >> wrote: >> >>> >>> >>> On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad >>> wrote: >>> Hi All, The text in the spec: 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. 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. >>> >> >> >
Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()
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. On Mon, Nov 16, 2015 at 12:38 PM, Justin Novosad 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 wrote: > >> >> >> On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad wrote: >> >>> Hi All, >>> >>> The text in the spec: >>> >>> >>> >>> 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. >>> >>> >>> >>> 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. >> > >
Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()
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 wrote: > > > On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad wrote: > >> Hi All, >> >> The text in the spec: >> >> >> >> 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. >> >> >> >> 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. >
Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()
On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad wrote: > Hi All, > > The text in the spec: > > > > 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. > > > > 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.
