old -- Fix for 32767 issue

src/effects/SkBlurMaskFilter.cpp

Index: src/effects/SkBlurMaskFilter.cpp
===================================================================
--- src/effects/SkBlurMaskFilter.cpp	(revision 12921)
+++ src/effects/SkBlurMaskFilter.cpp	(working copy)
@@ -321,6 +321,14 @@
 
     SkRect smallR = SkRect::MakeWH(totalSmallWidth, totalSmallHeight);
 
+    if (smallR.width() * smallR.height() > clipBounds.width() * clipBounds.height()) {
+        // This path creates the nine-patch and then draws it. The fallback
+        // path draws the clipped path, blurs it then blits it. If we are
+        // going to touch more pixels using this path we should probably just
+        // fall back.
+        return kUnimplemented_FilterReturn;
+    }
+
     SkRRect smallRR;
     SkVector radii[4];
     radii[SkRRect::kUpperLeft_Corner] = UL;
@@ -451,6 +459,24 @@
         SkASSERT(!smallR[1].isEmpty());
     }
 
+#if 0
+    // Both filterRectsToNine and filterRRectToNine share this problem
+    // (potentially trying to allocate too large a nine-patch mask). 
+    // Chromium is currently seeing the filterRRectToNine crash but we have
+    // not yet seen the filterRectsToNine corrolate. Presumably we will have 
+    // to enable this code some day but more testing is required (For example,
+    // since the analytic case is faster then the normal blur should we
+    // actually have a constant multiplier in the following inequality).
+    if (smallR[0].width() * smallR[0].height() >
+        clipBounds.width() * clipBounds.height()) {
+        // This path creates the nine-patch and then draws it. The fallback
+        // path draws the clipped path, blurs it then blits it. If we are
+        // going to touch more pixels using this path we should probably just
+        // fall back.
+        return kUnimplemented_FilterReturn;
+    }
+#endif
+
     if (count > 1 || !c_analyticBlurNinepatch) {
         if (!draw_rects_into_mask(smallR, count, &srcM)) {
             return kFalse_FilterReturn;