CPU implementation of Gaussian blur

A software implementation of the Gaussian blur filter, using 3 box blurs.  Also re-enable the imageblur GM test, since the SkPicture path now works.

[reed1, 2011-11-18 17:12:57]

imagefilter is responsible for creating the dst bitmap and offset. I will submit
a separate CL that invokes it, so this CL can just devolve to the blurfilter

[reed1, 2011-12-14 21:50:36]

SkBitmap's pixels are SkPMColor, not SkColor (though sometimes those are the
same). Therefore you just need to use the macros in SkColorPriv.h to get the
components (e.g. SkGetPackedA32 instead of SkColorGetA) and repack them with
SkPackARGB32.

Can we do anything faster for kernelSize divide? Can that be converted to a
large multiplier with a shift?

[TomH, 2011-12-15 19:54:28]

http://codereview.appspot.com/5413048/diff/7001/src/effects/SkBlurImageFilter...
File src/effects/SkBlurImageFilter.cpp (right):

http://codereview.appspot.com/5413048/diff/7001/src/effects/SkBlurImageFilter...
src/effects/SkBlurImageFilter.cpp:63: SkColor r = *(sptr + rightOffset + 1);
Why the +1s?

[Stephen White, 2011-12-16 16:12:35]

On 2011/12/14 21:50:36, reed1 wrote:
> SkBitmap's pixels are SkPMColor, not SkColor (though sometimes those are the
> same). Therefore you just need to use the macros in SkColorPriv.h to get the
> components (e.g. SkGetPackedA32 instead of SkColorGetA) and repack them with
> SkPackARGB32.

Done.
> 
> Can we do anything faster for kernelSize divide? Can that be converted to a
> large multiplier with a shift?

Yes, it's dumb.  The reason it's this way is so we have pixel-for-pixel
compatibility with the WebKit implementation for now.  My plan is to switch us
over to the skia impl, then change it to a hoisted float reciprocal and
multiply.  (Even with the float->int conversions, it was faster)  It just gave
slightly different results, so I wanted to do the switch first.

[Stephen White, 2011-12-16 16:20:31]

http://codereview.appspot.com/5413048/diff/7001/src/effects/SkBlurImageFilter...
File src/effects/SkBlurImageFilter.cpp (right):

http://codereview.appspot.com/5413048/diff/7001/src/effects/SkBlurImageFilter...
src/effects/SkBlurImageFilter.cpp:63: SkColor r = *(sptr + rightOffset + 1);
On 2011/12/15 19:54:28, TomH wrote:
> Why the +1s?

Basically, this is accumulating the "next" value into the sum, which is one
pixel to the right of the current accumulation window.  Another way to see this
would be to move the x++ (and spr++) from the for-loop to just before this "if".
 Then I think the +1's could be removed.  Do you think that would be clearer?

[Stephen White, 2011-12-20 19:23:38]

Ready for re-review.

[reed1, 2011-12-20 19:38:30]

lgtm

[Stephen White, 2011-12-20 20:54:40]

On 2011/12/20 19:38:30, reed1 wrote:
> lgtm

Landed as r2905; closing.