Moving 4 SkImageFilter derived classes from blink to skia

include/effects/SkXfermodeImageFilter.h

 /*
  * Copyright 2013 The Android Open Source Project
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 #ifndef SkXfermodeImageFilter_DEFINED
 #define SkXfermodeImageFilter_DEFINED
 
 #include "SkImageFilter.h"
 
 class SkBitmap;
 class SkXfermode;
 
 class SK_API SkXfermodeImageFilter : public SkImageFilter {
     /**
      * This filter takes an xfermode, and uses it to composite the foreground
      * over the background.  If foreground or background is NULL, the input
      * bitmap (src) is used instead.
       */
 
 public:
     SkXfermodeImageFilter(SkXfermode* mode, SkImageFilter* background,
-                          SkImageFilter* foreground = NULL);
+                          SkImageFilter* foreground = NULL, const SkIRect* cropRect = 0);

[mtklein, 2013/09/24 20:30:34]

= 0 -> = NULL?

[sugoi1, 2013/09/25 15:41:08]

Done.

 
     virtual ~SkXfermodeImageFilter();
 
     SK_DECLARE_PUBLIC_FLATTENABLE_DESERIALIZATION_PROCS(SkXfermodeImageFilter)
 
     virtual bool onFilterImage(Proxy* proxy,
                                const SkBitmap& src,
                                const SkMatrix& ctm,
                                SkBitmap* dst,
                                SkIPoint* offset) SK_OVERRIDE;
 #if SK_SUPPORT_GPU
-    virtual bool canFilterImageGPU() const SK_OVERRIDE { return true; }
+    virtual bool canFilterImageGPU() const SK_OVERRIDE { return cropRect().isLargest(); }

[sugoi1, 2013/09/24 20:08:17]

Are crop rects supported by default in GPU ? I conservatively assumed that it
wasn't the case, but I can remove this change if it is.

[Stephen White, 2013/09/24 23:14:13]

No, they're not. It looks like you've implemented them for the raster path,
which is great. You should also add some tests for this. If you like, you can
just copy xfermodeimagefilter GM and add a crop rect to each sample. You could
also do a reduced number of modes, just to handle the two different code paths
in the GPU code (is expressible as an effect, or a fixed-func blend mode). The
rest of the code should be adequately covered by the existing GM.

The GPU path can be left as-is for now, with the canFilterImageGPU() check as
you wrote it. Please log a bug, though, since there is some opportunity for
optimization: the GPU path applies the effect-style blending modes in a single
pass, which the generic onFilterImage() path does not. Also check for any minor
pixel diffs to layout tests in Chrome, and warn Rob if so.

     virtual bool filterImageGPU(Proxy* proxy, const SkBitmap& src, const SkMatrix& ctm,
                                 SkBitmap* result, SkIPoint* offset) SK_OVERRIDE;
 #endif
 
 protected:
     explicit SkXfermodeImageFilter(SkFlattenableReadBuffer& buffer);
     virtual void flatten(SkFlattenableWriteBuffer&) const SK_OVERRIDE;
 
 private:
     SkXfermode* fMode;
     typedef SkImageFilter INHERITED;
 };
 
 #endif