Fixes the rendering of a SVG filter (e.g. feFlood) by testing against total

Source/platform/graphics/filters/FilterEffect.cpp

Index: Source/platform/graphics/filters/FilterEffect.cpp
diff --git a/Source/platform/graphics/filters/FilterEffect.cpp b/Source/platform/graphics/filters/FilterEffect.cpp
index ce8f23f723481bd38b66d3446078b5c987ae6b66..29de7979b4bff5f31442bedacb9236095c94cf45 100644
--- a/Source/platform/graphics/filters/FilterEffect.cpp
+++ b/Source/platform/graphics/filters/FilterEffect.cpp
@@ -36,6 +36,9 @@
 
 namespace WebCore {
 
+const float FilterEffect::kMaxFilterArea(2 << 21);

[fs, 2014/02/07 10:17:51]

Nit: I think this would read more easily as "2048 * 2048" - or at least "1 <<
22" - the "2" is pretty confusing and easy to miss.

Also, isn't this a tad small?

[Stephen Chennney, 2014/02/11 14:47:21]

Yeah. I wanted 4096 x 4096.

static const float kMaxFilterArea = 4096 * 4096;

From memory compilers support constant expressions to define static constants.

+
+
 FilterEffect::FilterEffect(Filter* filter)
     : m_alphaImage(false)
     , m_filter(filter)
@@ -54,11 +57,27 @@ FilterEffect::~FilterEffect()
 {
 }
 
-inline bool isFilterSizeValid(IntRect rect)
+float FilterEffect::maxFilterArea()
 {
-    if (rect.width() < 0 || rect.width() > kMaxFilterSize
-        || rect.height() < 0 || rect.height() > kMaxFilterSize)
+    return kMaxFilterArea;
+}
+
+bool FilterEffect::isFilterSizeValid(FloatRect rect)

[Stephen Chennney, 2014/02/11 14:47:21]

Should be const FloatRect&.

+{
+    if (rect.width() < 0 || rect.height() < 0
+        ||  (rect.height() * rect.width() > kMaxFilterArea))
         return false;
+
+    return true;
+}
+
+
+bool FilterEffect::isFilterSizeValid(IntRect rect)

[Stephen Chennney, 2014/02/11 14:47:21]

Should be const IntRect&.

+{
+    if (rect.width() < 0 || rect.height() < 0
+        ||  (rect.height() * rect.width() > kMaxFilterArea))

[Stephen White, 2014/02/11 15:20:35]

Is there is a danger of overflow here? The multiply will be done in integer,
then promoted to float for the comparison. So it could overflow and fail the
compare while being larger than max.

It might actually be safer to simply construct a FloatRect from the argument,
and pass that through to the other version. Then the multiply will be done in
float. (There would be a loss of precision for very large ints, but I think it
would still do the right thing, since at the point where this occurs, all values
will be above max anyway and will pass the compare.)

Another option would be to cast to int64_t before the multiply, but I think
floats would give the same result with less code.

+        return false;
+
     return true;
 }