detect when we can filter bitmaps/images directly, w/o a tmp layer

include/core/SkDevice.h

Index: include/core/SkDevice.h
diff --git a/include/core/SkDevice.h b/include/core/SkDevice.h
index c52c579424a2ad7e450b501585052d0aa8eea050..e30e810aa95952c3c22d1f70c08dce6c69df2510 100644
--- a/include/core/SkDevice.h
+++ b/include/core/SkDevice.h
@@ -374,9 +374,14 @@ private:
     friend class SkDeviceFilteredPaint;
     friend class SkImageFilter::DeviceProxy;
     friend class SkNoPixelsBitmapDevice;
-
     friend class SkSurface_Raster;
 
+    /**
+     *  Will invoke the paint's imagefilter directly on the bitmap, and draw the result.
+     *  Assumes that the caller has previously called canCallFilterSprite().
+     */
+    void filterSprite(const SkDraw&, const SkBitmap&, int x, int y, const SkPaint&);

[Stephen White, 2015/12/04 19:22:51]

Since we're getting rid of drawSprite(), could we just call this filterBitmap(),
so it's not the lone Sprite-related thingy?

Come to think of it, this name is misleading wrt filterImage(), which actually
returns the filtered image (vs. this one, which draws it to the device).

Maybe drawBitmapAsSprite? drawBitmapFast()? fastDrawBitmap()?
drawFilteredBitmap()? (I think I like the last one best, but if there are other
possible optimizations here, maybe drawBitmapFast()?)

[reed1, 2015/12/04 19:33:29]

Agreed, the name is weird.

drawBitmapAsSprite sgtm.

+
     // used to change the backend's pixels (and possibly config/rowbytes)
     // but cannot change the width/height, so there should be no change to
     // any clip information.