Allow Convexicator to implicitly close correctly

In the old code, fFirstPt actually pointed to the first added point that
came *after* a call to setMovePt. The moved-to point that started the
contour was never remembered in the Convexicator, so it required the
SkPath::Iter to force close. When the iterator force-closed, it made
sure to add a line-to back to the start of the contour, which it could
do because the Iter was also tracking the contours.
 - It's important that the old code's close()'s addPt(fFirstPt) actually
   re-added the first point after the move-to because it catches
   concavities that occur at vertex that started the contour. The first
   time that point is added, we have no initial vector to check for
   direction changes against.

In the new code, I've updated the state tracking to be more straight
forward. fCurrPt and fLastPt were redundant (they always equaled each
other once addPt returned). fPriorPt was also redundant when combined
with the expected direction enum, since it's only use was to determine
when to cache the initial vector. I also found it confusing to know
the difference between fLastPt and fPriorPt based just on variable

Now fFirstPt refers to the location of the moveTo/"start of contour",
and fFirstVec is the direction vector leaving that point to the next
point in the contour. fLastPt is the point that was last passed to
addPt and fLastVec is the direction that comes into 'fLastPt'.  The
close() function is updated to add a point back to fFirstPt (which does
nothing if the close is explicit, or handled by SkPath::Iter) AND it
checks for a dir change on the first vector.

This shouldn't change any behavior, so I wanted it as a standalone
change, but it will allow to
update computeConvexity() to move away from

Bug: skia:1187385
Change-Id: Iff383693956b28e3c21b23e5a5c6ce814227bb27
Reviewed-by: Chris Dalton <>
Commit-Queue: Michael Ludwig <>
1 file changed