Add a PNGEncoder helper function that takes an SkBitmap,

Add a PNGEncoder helper function that takes an SkBitmap,
which is how PNGEncode is used almost everywhere.

This should be strictly no functional change, except for the
ImageFilterPeer::DataReady case, where we now take an
SkAutoLockPixels where previously we did not.

[ncarter (slow), 2009-01-21 01:12:26]

Tim, could you review?

[tim (not reviewing), 2009-01-21 19:12:50]

http://codereview.chromium.org/18347/diff/208/9
File base/gfx/png_encoder.cc (right):

http://codereview.chromium.org/18347/diff/208/9#newcode202
Line 202: input.width()* 4, discard_transparency, output);
I think instead of input.width() * 4 we should be using input.rowBytes() since
(as Encode mentions) sometimes the bitmaps can have padded rows.

[ncarter (slow), 2009-01-21 22:51:28]

Patch set updated.

[tim (not reviewing), 2009-01-22 00:32:41]

This looks good to me but I don't know much about SecurityFilterPeer, other than
I think it has something to do with the "Block all insecure content/Allow all
content to load" Security setting, swapping insecure images or something. 

Like you mentioned in person, this code means we now use an SkAutoLockPixels
when encoding wheras before we didn't, and it's the only place we've found that
*didn't* do so before. 
cc'ing jcampan (the svn blame result) to possibly shed some light.

[tim (not reviewing), 2009-01-22 01:05:20]

On 2009/01/22 00:32:41, timsteele wrote:
> This looks good to me but I don't know much about SecurityFilterPeer, other
than
> I think it has something to do with the "Block all insecure content/Allow all
> content to load" Security setting, swapping insecure images or something. 
> 
> Like you mentioned in person, this code means we now use an SkAutoLockPixels
> when encoding wheras before we didn't, and it's the only place we've found
that
> *didn't* do so before. 
> cc'ing jcampan (the svn blame result) to possibly shed some light.

LGTM!