Fixed bug #1251296

This is a regression that is causing me to wonder why it ever worked in
the first place. The underflow bug was getting tripped by a very small scaling
matrix being improperly treated as a zero matrix, and also, the scaling code
was getting bitten by a bug in Skia's edge comparison function which caused
incorrect results to be returned when the difference between two values
exceeded the maximum signed integer.


git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1180 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 8 insertions, 7 deletions

diff --git a/webkit/port/platform/graphics/SkiaUtils.cpp b/webkit/port/platform/graphics/SkiaUtils.cpp
index 89e6998..27779c7 100644
--- a/webkit/port/platform/graphics/SkiaUtils.cpp
+++ b/webkit/port/platform/graphics/SkiaUtils.cpp
@@ -211,14 +211,15 @@ bool SkPathContainsPoint(SkPath* orig_path, WebCore::FloatPoint point, SkPath::F
 
     orig_path->setFillType(ft);
 
-    // Skia has trouble with coordinates greater than +/- 2^15... if we have
-    // those, we need to scale
+    // Skia has trouble with coordinates close to the max signed 16-bit values
+    // If we have those, we need to scale. 
+    //
+    // TODO: remove this code once Skia is patched to work properly with large
+    // values
     const SkScalar kMaxCoordinate = SkIntToScalar(1<<15);
-    SkScalar biggest_coord = 0;
-    biggest_coord = -bounds.fLeft   > biggest_coord ? -bounds.fLeft   : biggest_coord;
-    biggest_coord = -bounds.fTop    > biggest_coord ? -bounds.fTop    : biggest_coord;
-    biggest_coord =  bounds.fRight  > biggest_coord ?  bounds.fRight  : biggest_coord;
-    biggest_coord =  bounds.fBottom > biggest_coord ?  bounds.fBottom : biggest_coord;
+    SkScalar biggest_coord = std::max(std::max(std::max(
+      bounds.fRight, bounds.fBottom), -bounds.fLeft), -bounds.fTop);
+
     if (biggest_coord > kMaxCoordinate) {
       scale = SkScalarCeil(SkScalarDiv(biggest_coord, kMaxCoordinate));