avoid generating degenerate conic from arc

src/core/SkGeometry.cpp

Index: src/core/SkGeometry.cpp
diff --git a/src/core/SkGeometry.cpp b/src/core/SkGeometry.cpp
index 03a63b2bdad93df6914210968284db92f061b4c9..8f270f9722c66f59bbad86c2168f291c0b760cb6 100644
--- a/src/core/SkGeometry.cpp
+++ b/src/core/SkGeometry.cpp
@@ -1351,8 +1351,10 @@ int SkConic::BuildUnitArc(const SkVector& uStart, const SkVector& uStop, SkRotat
         //
         const SkScalar cosThetaOver2 = SkScalarSqrt((1 + dot) / 2);
         offCurve.setLength(SkScalarInvert(cosThetaOver2));
-        dst[conicCount].set(lastQ, offCurve, finalP, cosThetaOver2);
-        conicCount += 1;
+        if (!lastQ.equalsWithinTolerance(offCurve)) {
+            dst[conicCount].set(lastQ, offCurve, finalP, cosThetaOver2);
+            conicCount += 1;
+        } 

[Mark Kilgard, 2016/08/26 17:13:07]

I don't like this epsilon handling here.  It's just going to shift the issue.

The method looks much as I expected it to look.  It divides large arcs into 90
degree quadrants.

Can you instead figure out how many even segments to divide the arc into?

This approach has two advantages:
1) more stable, no epsilon change
2) each conic's w value will be identical

Example:  If the angle is 200 degrees, notice that ceil(200/90) is 3 (2.222
rounds up to 3) then 200/3 = 66.66.  Now you can do the sqrt((1+dot)/2) math to
determine a single w where dot is cos of 66.66 degrees.

Make sense?  I think this can be a simpler overall algorithm than what you have
here.

Keep in mind if somebody had a abnormally large miter limit and used a miter
join, they might still be able to get zinged join geometry.

     }
 
     // now handle counter-clockwise and the initial unitStart rotation