"Fix" case when bicubic filtering warps premultiplied color

When the bicubicfilter test is altered as shown, the pre-multiplied color asserts in SkPackARGB32 fire. This happens when the following four colors are being filtered (in cubicBlend):
		c0	0x00000000	
		c1	0x00000000	
		c2	0xffffffff	
		c3	0xff000000	
yielding:
		a	0x00000012
		r	0x00000013
		g	0x00000013
		b	0x00000013

The proposed fix is to just clamp the premultiplied alpha to be the max of the r,g,b components

[reed1, 2013-03-04 20:16:44]

1. I suggest we make the new packer private for now, since this is the only
user.
2. Not sure promoting alpha is better than demoting r,g,b (i.e. compute alpha
first, and then make sure r,g,b stay <= alpha. How did you pick the direction
you're proposing?

[robertphillips, 2013-03-04 20:46:50]

Folding the clamp into the cubicBlend function works much better. The choice of
making 'a' the max of r,g,b was arbitrary. Given the scale of the observed
difference the direction of the move didn't seem important.

[Stephen White, 2013-03-06 15:02:08]

https://codereview.appspot.com/7447048/diff/1/gm/bicubicfilter.cpp
File gm/bicubicfilter.cpp (right):

https://codereview.appspot.com/7447048/diff/1/gm/bicubicfilter.cpp#newcode70
gm/bicubicfilter.cpp:70: //        canvas->restore();
Note that this change will cause the bicubic test to filter all of the source
canvas pixels, which will slow it down significantly, IIRC.  The way it's
written currently is the only way I could find to have an image filter resize
its input, while constraining it to a size in source pixel space.

I wonder if the out-of-PM-range colours you're seeing are the result of some
uninitialized pixels in the canvas?  Or bad x/y range checking in the bicubic
filter?

[robertphillips, 2013-03-06 15:16:06]

https://codereview.appspot.com/7447048/diff/1/gm/bicubicfilter.cpp
File gm/bicubicfilter.cpp (right):

https://codereview.appspot.com/7447048/diff/1/gm/bicubicfilter.cpp#newcode70
gm/bicubicfilter.cpp:70: //        canvas->restore();
I'm not proposing to deliver the changes to bicubicfilter.cpp - it was just how
I first saw the issue. Given the pixel values that cause the problem it seems
like it should be possible to cause the problem with a more controlled input.

[robertphillips, 2013-03-11 19:33:43]

ping

[reed1, 2013-03-11 20:09:43]

lgtm, but seems like blanco needs to approve too.

[Stephen White, 2013-03-11 20:15:31]

On 2013/03/11 20:09:43, reed1 wrote:
> lgtm, but seems like blanco needs to approve too.

I'm going to dig in a little deeper to see if this is endemic, or avoidable.

[Stephen White, 2013-03-11 20:35:38]

On 2013/03/11 20:15:31, Stephen White wrote:
> On 2013/03/11 20:09:43, reed1 wrote:
> > lgtm, but seems like blanco needs to approve too.
> 
> I'm going to dig in a little deeper to see if this is endemic, or avoidable.

Nope, it's unavoidable.  LGTM

[robertphillips, 2013-03-12 13:13:32]

committed as r8096