Factor painting code for filters out of FilterEffectRenderer into FilterPainter.

Source/core/paint/FilterPainter.h

Index: Source/core/paint/FilterPainter.h
diff --git a/Source/core/paint/FilterPainter.h b/Source/core/paint/FilterPainter.h
new file mode 100644
index 0000000000000000000000000000000000000000..513d492d6e56d758c6a8b5a177c6268fafe26381
--- /dev/null
+++ b/Source/core/paint/FilterPainter.h
@@ -0,0 +1,26 @@
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef FilterPainter_h
+#define FilterPainter_h
+
+namespace blink {
+
+class FloatRect;
+class GraphicsContext;
+class RenderLayer;
+
+class FilterPainter {
+public:
+    FilterPainter(RenderLayer& layer) : m_renderLayer(layer) { }
+    bool beginFilterEffect(GraphicsContext*, const FloatRect& filterBoxRect);
+    void endFilterEffect(GraphicsContext*);
+
+private:
+    RenderLayer& m_renderLayer;

[Stephen White, 2014/11/11 03:53:24]

Since all we need out of the RenderLayer is
m_renderLayer.filterRenderer()->lastEffect(), I wonder if we should just pass
that to the FilterPainter instead in beginFilterEffect(). It would reduce
dependencies (and avoid a cyclic one between this class and
FilterEffectRenderer). Just a thought.

[chrishtr, 2014/11/11 22:21:37]

This is the standard pattern for these painting classes, so I'd prefer to stick
with it unless we see a perf regression. I'm quite confident we will see none
for filters, since they are not a hotspot in this way.

[chrishtr, 2014/11/11 22:21:37]

This is the standard pattern for these painting classes, so I'd prefer to stick
with it unless we see a perf regression. I'm quite confident we will see none
for filters, since they are not a hotspot in this way.

+};
+
+} // namespace blink
+
+#endif // FilterPainter_h