AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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

Browse Source 
This reverts commit bc721ba4be.

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>
This commit is contained in:
Mike Klein 2018-05-22 12:19:13 +00:00 committed by Skia Commit-Bot
parent e62b5c3d10
commit 8afa554414
2 changed files with 1 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/core/SkPath.cpp
View File

@ -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

21
tests/PathTest.cpp
View File

@ -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);
}