Revert "remove fragile hack in addOval to avoid computing bounds"

This reverts commit bc721ba4be626e3ba753f55341a7019d98044102.

Reason for revert: I think we'll want to reland with guards for layout tests.  https://test-results.appspot.com/data/layout_results/linux_trusty_blink_rel/29630/layout-test-results/results.html


Original change's description:
> remove fragile hack in addOval to avoid computing bounds
> 
> Bug: skia:
> Change-Id: Ide917f54633370f1fce46a115fa923794b981e2e
> Reviewed-on: https://skia-review.googlesource.com/129461
> Reviewed-by: Mike Klein <mtklein@google.com>
> Commit-Queue: Mike Reed <reed@google.com>

TBR=mtklein@google.com,reed@google.com

Change-Id: Ibadac8bbeca2b162d696e7cca51d580121afe71f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/129442
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>

2 files changed, 1 insertions, 24 deletions

diff --git a/src/core/SkPath.cpp b/src/core/SkPath.cpp
index 7a0f82800c..510efd6d9d 100644
--- a/src/core/SkPath.cpp
+++ b/src/core/SkPath.cpp
@@ -1252,9 +1252,7 @@ void SkPath::addOval(const SkRect &oval, Direction dir, unsigned startPointIndex
     }
 
     SkAutoDisableDirectionCheck addc(this);
-    // unlike addRect(), we can't use SkAutoPathBoundsUpdate here, since even with a finite
-    // bounds, we might (due to an overflow in intermediate calculations) create a nonfinite
-    // path.
+    SkAutoPathBoundsUpdate apbu(this, oval);
 
     SkDEBUGCODE(int initialVerbCount = this->countVerbs());
     const int kVerbs = 6; // moveTo + 4x conicTo + close
diff --git a/tests/PathTest.cpp b/tests/PathTest.cpp
index 9885a92351..9d8c18f997 100644
--- a/tests/PathTest.cpp
+++ b/tests/PathTest.cpp
@@ -5051,24 +5051,3 @@ DEF_TEST(Path_isRect, reporter) {
     compare.set(&points53[1], 4);
     REPORTER_ASSERT(reporter, rect == compare);
 }
-
-/*
- *  addOval (which is called by bitmapdevice::drawOval) used to assume that if the bounds were
- *  finite, then the resulting path would be too. However, with the right (i.e. nasty) coordinates,
- *  its possible to make the calculation of the path overflow float and produce a nonfinite path.
- *  The fix was easy -- we just remove that assumption from addOval, and instead let it (lazily)
- *  compute the path as normal (i.e. just the same as if the client has made the calls to construct
- *  a path from conics).
- *
- *  Before the fix, this test would assert
- */
-DEF_TEST(giant_ovals, reporter) {
-    SkPaint paint;
-    SkRect r = {  -3.01901558E+38f, 0, -5.32108205E+37f, 10 };
-
-    auto surface(SkSurface::MakeRasterN32Premul(84, 88));
-    SkCanvas* canvas = surface->getCanvas();
-
-    canvas->translate(-r.fLeft, 0);
-    canvas->drawOval(r, paint);
-}