perpendicular round rects; fuzzy convexity

Construct round rects with perpendicular tangents.
    
The round rects are constructed as before out of quadratics, 
but without fudging the control points. Instead, the mid on-
curve point is nudged slightly outward to prevent the
convexity test from failing.
    
The convexity test now includes an error term for sign
inequality after computing the cross product of the control
lines. When the control points are represented as vectors,
the number of bits of precision may be greatly reduced.

Account for this by passing the number of bits available
from the original control point values into the equality
check.

Making round rect construction lines perpendicular improves
the chances of success when path ops encounters clips.
    
No new tests are needed -- this change is exercised by the
convex Path unit tests and the gm tests arcofzorro and
hairlines.

Committed: http://code.google.com/p/skia/source/detail?r=12085

[robertphillips, 2013-10-28 14:16:54]

lgtm + a comment suggestion

https://codereview.chromium.org/48783002/diff/30001/src/core/SkGeometry.cpp
File src/core/SkGeometry.cpp (right):

https://codereview.chromium.org/48783002/diff/30001/src/core/SkGeometry.cpp#n...
src/core/SkGeometry.cpp:1259: static const SkPoint
gQuadCirclePts[kSkBuildQuadArcStorage] = {
Possibly a comment here explaining what/how SK_MID_RRECT_OFFSET does/was
derived?

[caryclark, 2013-10-28 14:25:32]

https://codereview.chromium.org/48783002/diff/30001/src/core/SkGeometry.cpp
File src/core/SkGeometry.cpp (right):

https://codereview.chromium.org/48783002/diff/30001/src/core/SkGeometry.cpp#n...
src/core/SkGeometry.cpp:1259: static const SkPoint
gQuadCirclePts[kSkBuildQuadArcStorage] = {
On 2013/10/28 14:16:55, robertphillips wrote:
> Possibly a comment here explaining what/how SK_MID_RRECT_OFFSET does/was
> derived?

Done.

[reed1, 2013-10-29 20:50:06]

https://codereview.chromium.org/48783002/diff/130001/src/core/SkGeometry.cpp
File src/core/SkGeometry.cpp (right):

https://codereview.chromium.org/48783002/diff/130001/src/core/SkGeometry.cpp#...
src/core/SkGeometry.cpp:1264: #define SK_MID_RRECT_OFFSET (SK_Scalar1 +
SK_ScalarTanPIOver8 + FLT_EPSILON * 4) / 2
static const SkScalar gMidRRectOffset = ...;

is that just as efficient? If so, it might be more readable than a #define
(followed by an undef).

https://codereview.chromium.org/48783002/diff/130001/src/core/SkPath.cpp
File src/core/SkPath.cpp (right):

https://codereview.chromium.org/48783002/diff/130001/src/core/SkPath.cpp#newc...
src/core/SkPath.cpp:2370: SkScalar cross = SkPoint::CrossProduct(fVec0, fVec1);
I need some comment block or other way to know what we're doing now.

[reed1, 2013-10-29 20:50:37]

do we already have some test or gm that exercises the new AlmostEqual code?

[caryclark, 2013-10-30 16:31:27]

On 2013/10/29 20:50:37, reed1 wrote:
> do we already have some test or gm that exercises the new AlmostEqual code?

Yes. The path convexity test fails with the geometry change to make the rrect
tangents perpendicular.

[reed1, 2013-10-30 17:36:16]

lgtm

[commit-bot: I haz the power, 2013-11-01 13:03:51]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/caryclark@google.com/48783002/250001

[commit-bot: I haz the power, 2013-11-01 13:03:54]

Failed to apply patch for expectations/gm/ignored-tests.txt:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file expectations/gm/ignored-tests.txt
  Hunk #1 FAILED at 43.
  1 out of 1 hunk FAILED -- saving rejects to file
expectations/gm/ignored-tests.txt.rej

Patch:       expectations/gm/ignored-tests.txt
Index: expectations/gm/ignored-tests.txt
diff --git a/expectations/gm/ignored-tests.txt
b/expectations/gm/ignored-tests.txt
index
209522a815bbf6ed4dad1e25085dad90cbcba03f..26ff965e11556424441c936d4ef63dfc885c72b4
100644
--- a/expectations/gm/ignored-tests.txt
+++ b/expectations/gm/ignored-tests.txt
@@ -43,3 +43,21 @@ verylargebitmap
 # Add by robertphillips in https://codereview.chromium.org/50813002/
 morphology
 
+# Added by caryclark in https://codereview.chromium.org/48783002/
+complexclip2_path_aa
+complexclip2_path_bw
+convexpaths
+mixed_xfermodes
+nested_aa
+ninepatch-stretch
+pathfill
+pathinterior
+pathopsskpclip
+roundrects
+rrect
+rrect_clip
+samplerstress
+simpleaaclip_aaclip
+simpleaaclip_path
+strokerect
+strokes_round

[commit-bot: I haz the power, 2013-11-01 13:22:12]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/caryclark@google.com/48783002/300001

[commit-bot: I haz the power, 2013-11-01 15:24:58]

Change committed as 12085

[scroggo, 2013-11-01 16:04:10]

https://codereview.chromium.org/48783002/diff/300001/src/core/SkPath.cpp
File src/core/SkPath.cpp (right):

https://codereview.chromium.org/48783002/diff/300001/src/core/SkPath.cpp#newc...
src/core/SkPath.cpp:2264: static bool AlmostEqual(SkScalar compA, SkScalar
compB) {
Is this deliberately different from SkScalarNearlyEqual in SkScalar.h?

Also, should this function go in SkScalar.h?

[caryclark, 2013-11-01 17:11:35]

On 2013/11/01 16:04:10, scroggo wrote:
> https://codereview.chromium.org/48783002/diff/300001/src/core/SkPath.cpp
> File src/core/SkPath.cpp (right):
> 
>
https://codereview.chromium.org/48783002/diff/300001/src/core/SkPath.cpp#newc...
> src/core/SkPath.cpp:2264: static bool AlmostEqual(SkScalar compA, SkScalar
> compB) {
> Is this deliberately different from SkScalarNearlyEqual in SkScalar.h?
> 
> Also, should this function go in SkScalar.h?

Yes, it is deliberately different. 

SkScalarNearlyEqual does not consider the magnitude of the number, so it is not
useful for replacing == with a form that allows for computational error.

The error factor baked into AlmostEqual is the number of bits required to
satisfy the error produced by the cross product in the convexity test.

You'll find a host of similar routines in src/pathops/SkPathOpsTypes.h, with
different values for the baked in error, which varies depending on the
computation of the caller.

Eventually, it makes sense to extract AlmostEqual as a generally callable
function, but for now, I recommend leaving in SkPath.cpp.

As for SkScalarNearlyEqual, I have not looked at its use cases to understand if
its present form is best, or if it should consider magnitude.