Simple cleanups related to SkFixed.

src/core/SkPaint.cpp

Index: src/core/SkPaint.cpp
diff --git a/src/core/SkPaint.cpp b/src/core/SkPaint.cpp
index cea3d0fc8dde623e16bfa8a538166438a43ea264..49e3a5ab9c2b4987c0136b3bb78de24d8ac4617f 100644
--- a/src/core/SkPaint.cpp
+++ b/src/core/SkPaint.cpp
@@ -1028,7 +1028,7 @@ size_t SkPaint::breakText(const void* textD, size_t length, SkScalar maxWidth,
     SkMeasureCacheProc glyphCacheProc = paint.getMeasureCacheProc(false);
     const int        xyIndex = paint.isVerticalText() ? 1 : 0;
     // use 64bits for our accumulator, to avoid overflowing 16.16
-    Sk48Dot16        max = SkScalarToFixed(maxWidth);
+    Sk48Dot16        max = SkScalarTo48Dot16(maxWidth);

[reed1, 2016/02/11 21:43:44]

Wow, this seems like a bug bug. Is/was there a test that showed this bug?

[dogben, 2016/02/11 21:53:13]

The previous code was actually fine, assuming maxWidth is within the range of
SkFixed. Casting from SkFixed (aka Sk16Dot16) to Sk48Dot16 is just adding zeros
(or ones) on the left.

[reed1, 2016/02/11 22:22:59]

So we could write a test that measures a big string (e.g. at a large
point-size), and see it overflow the SkFixed?

[dogben, 2016/02/12 02:35:24]

Oh! For some reason I was thinking that was the width of one glyph.

Large point-size is handled by scaling down the font and the maxWidth, so that's
not a problem.

However, this method previously could only handle ~5kB of text at the default
size. The fix allows it to handle more than 1GB.

     Sk48Dot16        width = 0;
 
     SkAutoKern  autokern;