Fix uninitialized memory on kIndex8 divisor tests in Gold

Fix uninitialized memory on kIndex8 divisor tests in Gold

Turns out bitmap.eraseColor() does nothing if the bitmap
is kIndex8.  We need a more reliable way to initialize
all of the pixels that we look at in Gold.

The input SkCanvas* is always zero initialized, so let's
only draw pixels to the canvas if we have initialized them.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/fa23a9ec4e7540f4e6222f6efadd29c1e711178f

[msarett, 2015-10-21 19:52:12]

Description was changed from

==========
Fix uninitialized memory on kIndex8 divisor tests in Gold

BUG=skia:
==========

to

==========
Fix uninitialized memory on kIndex8 divisor tests in Gold

Turns out bitmap.eraseColor() does nothing if the bitmap
is kIndex8.  We need a more reliable way to initialize
all of the pixels that we look at in Gold.

The input SkCanvas* is always zero initialized, so let's
only draw pixels to the canvas if we have initialized them.

BUG=skia:
==========

[msarett, 2015-10-21 19:53:16]

msarett@google.com changed reviewers:
+ scroggo@google.com

[scroggo, 2015-10-21 20:08:48]

> The input SkCanvas* is always zero initialized, so let's
> only draw pixels to the canvas if we have initialized them.

Interesting. I did not realize this!

Ok, so if I follow along, the canvas that is passed to draw() is initialized to
0, but we are drawing first to a bitmap, which is then drawn to that canvas. We
never initialize the bitmap.

This fixes the problem by only drawing the part we drew to?

I can think of a couple other fixes:
- draw to the canvas directly
  - Maybe this is too messy. Need to call peekPixels, const_cast to write to
them...
    - it also assumes raster canvas - currently true, but no good if we do YUV
- use a clip (not sure if this is any better than drawBitmapRect)

lgtm

[msarett, 2015-10-21 20:17:33]

On 2015/10/21 20:08:48, scroggo wrote:
> > The input SkCanvas* is always zero initialized, so let's
> > only draw pixels to the canvas if we have initialized them.
> 
> Interesting. I did not realize this!
> 
> Ok, so if I follow along, the canvas that is passed to draw() is initialized
to
> 0, but we are drawing first to a bitmap, which is then drawn to that canvas.
We
> never initialize the bitmap.
> 
> This fixes the problem by only drawing the part we drew to?

Yes that is correct!

> 
> I can think of a couple other fixes:
> - draw to the canvas directly
>   - Maybe this is too messy. Need to call peekPixels, const_cast to write to
> them...

We could do this for 8888 and 565, but I don't think we could decode to canvas
directly when decoding to other color types.

>     - it also assumes raster canvas - currently true, but no good if we do YUV

Good point.

> - use a clip (not sure if this is any better than drawBitmapRect)

Hmmm didn't think of this, but it's a similar idea.

> 
> lgtm

[msarett, 2015-10-21 20:18:04]

The CQ bit was checked by msarett@google.com

[commit-bot: I haz the power, 2015-10-21 20:18:08]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1418913002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1418913002/1

[commit-bot: I haz the power, 2015-10-21 20:27:02]

Committed patchset #1 (id:1) as
https://skia.googlesource.com/skia/+/fa23a9ec4e7540f4e6222f6efadd29c1e711178f