don't get dismayed by negative scales for HQ

src/core/SkBitmapController.cpp

Index: src/core/SkBitmapController.cpp
diff --git a/src/core/SkBitmapController.cpp b/src/core/SkBitmapController.cpp
index f4d352507aa616dba7012a677dfce95ad0cad52d..7a317b8c2f324f58b9abb0d15b1043986ba108a7 100644
--- a/src/core/SkBitmapController.cpp
+++ b/src/core/SkBitmapController.cpp
@@ -65,7 +65,11 @@ static inline bool cache_size_okay(const SkBitmapProvider& provider, const SkMat
     // return ((origBitmapSize * matrixScaleFactor) < maximumAllocationSize);
     // Skip the division step:
     const size_t size = provider.info().getSafeSize(provider.info().minRowBytes());
-    return size < (maximumAllocation * invMat.getScaleX() * invMat.getScaleY());
+    SkScalar invScaleSqr = invMat.getScaleX() * invMat.getScaleY();

[vmpstr, 2016/02/04 17:56:07]

I forgot to mention this, but there's another small issue here with rotations.
If we have a rotated image (but otherwise unscaled), then these scales are not
correct. It again doesn't really affect much since it only changes the perceived
amount that the decode requires, but maybe we can rework this and reuse the
scales we get in processHQRequest instead. 

+#ifndef SK_SUPPORT_LEGACY_NEG_SCALE_HQ
+    invScaleSqr = SkScalarAbs(invScaleSqr);
+#endif
+    return size < (maximumAllocation * invScaleSqr);
 }
 
 /*
@@ -97,6 +101,11 @@ bool SkDefaultBitmapControllerState::processHQRequest(const SkBitmapProvider& pr
         invScaleX = scale.width();
         invScaleY = scale.height();
     }
+#ifndef SK_SUPPORT_LEGACY_NEG_SCALE_HQ
+    invScaleX = SkScalarAbs(invScaleX);
+    invScaleY = SkScalarAbs(invScaleY);
+#endif
+
     if (SkScalarNearlyEqual(invScaleX, 1) && SkScalarNearlyEqual(invScaleY, 1)) {
         return false; // no need for HQ
     }