Scanline Subset Mode for DM Correctness Test

New CodeSrc* draw mode kScanline_Subset_Mode 

kScanline_Subset_Mode decodes the image in subsets using a
scanline decoder.
The number of subsets can be specified by changing the constant divisor.
The number of subsets is equal to divisor*divisor.

Committed: https://skia.googlesource.com/skia/+/9700206b67ef2a0aab9a8211c8a901d5123afa9f

[emmaleer, 2015-05-26 22:41:27]

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

[emmaleer, 2015-05-26 22:43:25]

No new changes, just creating new cl with emmaleer@google.com account so I can
upload code when finished.

[scroggo, 2015-05-27 13:51:40]

lgtm. Let's keep an eye on status.skia.org/gold.skia.org to see if there are any
new images that look wrong.

[scroggo, 2015-05-27 13:52:14]

On 2015/05/27 13:51:40, scroggo wrote:
> lgtm. Let's keep an eye on http://status.skia.org/gold.skia.org to see if
there are any
> new images that look wrong.

That is, status.skia.org and gold.skia.org, not a url of the two smashed
together...

[emmaleer, 2015-05-27 15:42:09]

The CQ bit was checked by emmaleer@google.com

[commit-bot: I haz the power, 2015-05-27 15:42:21]

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

[emmaleer, 2015-05-27 15:43:04]

The CQ bit was unchecked by emmaleer@google.com

[emmaleer, 2015-05-27 18:35:07]

added check to handle w*h == 1 error

[scroggo, 2015-05-27 18:35:42]

The CQ bit was checked by scroggo@google.com

[scroggo, 2015-05-27 18:35:43]

lgtm

[commit-bot: I haz the power, 2015-05-27 18:36:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1157153003/40001

[commit-bot: I haz the power, 2015-05-27 18:41:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-05-27 18:41:03]

Try jobs failed on following builders:
  Build-Win-MSVC-x86-Debug-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Win-MSVC-x86-D...)

[emmaleer, 2015-05-27 18:56:59]

What is the common practice for using int vs SkScalar?
There was an error that w and h needed to be SkScalar to use the canvas->draw
function.
Should I change other int's (like subsetWidth, divisor, extraX etc.) to SkScalar
also?
Only w and h caused an error for being int's, just wondering if using SkScalar
is preferred.

[scroggo, 2015-05-27 19:09:41]

On 2015/05/27 18:56:59, emmaleer wrote:
> What is the common practice for using int vs SkScalar?
> There was an error that w and h needed to be SkScalar to use the canvas->draw
> function.
> Should I change other int's (like subsetWidth, divisor, extraX etc.) to
SkScalar
> also?
> Only w and h caused an error for being int's, just wondering if using SkScalar
> is preferred.

not lgtm

int is for when you want an integer. SkScalar is a typdef for float (which you
can find in SkScalar.h). (A little history - SkScalar used to be a fixed point
number instead of floating point. We eventually removed support for SkScalar ==
SkFixed, and eventually we may make it a double.)

I don't think w and h are the problem. Looking at
http://build.chromium.org/p/client.skia.compile/builders/Build-Win-MSVC-x86_6...,
it appears that the problem is on line 255, where you call
SkCanvas::drawBitmap(subsetBm, x, y), which takes SkScalar parameters. (If
you're using an API, you want the type that the API needs.)

We have a macro for converting an int to an SkScalar (again, in SkScalar.h):
SkIntToScalar

[emmaleer, 2015-05-27 19:18:07]

On 2015/05/27 19:09:41, scroggo wrote:
> On 2015/05/27 18:56:59, emmaleer wrote:
> > What is the common practice for using int vs SkScalar?
> > There was an error that w and h needed to be SkScalar to use the
canvas->draw
> > function.
> > Should I change other int's (like subsetWidth, divisor, extraX etc.) to
> SkScalar
> > also?
> > Only w and h caused an error for being int's, just wondering if using
SkScalar
> > is preferred.
> 
> not lgtm
> 
> int is for when you want an integer. SkScalar is a typdef for float (which you
> can find in SkScalar.h). (A little history - SkScalar used to be a fixed point
> number instead of floating point. We eventually removed support for SkScalar
==
> SkFixed, and eventually we may make it a double.)
> 
> I don't think w and h are the problem. Looking at
>
http://build.chromium.org/p/client.skia.compile/builders/Build-Win-MSVC-x86_6...,
> it appears that the problem is on line 255, where you call
> SkCanvas::drawBitmap(subsetBm, x, y), which takes SkScalar parameters. (If
> you're using an API, you want the type that the API needs.)
> 
> We have a macro for converting an int to an SkScalar (again, in SkScalar.h):
> SkIntToScalar

>Okay thanks! I now use the SkIntToScalar marco to convert x and y to SkScalar
when calling drawBitmap

[scroggo, 2015-05-27 19:23:01]

On 2015/05/27 19:18:07, emmaleer wrote:
> On 2015/05/27 19:09:41, scroggo wrote:
> > On 2015/05/27 18:56:59, emmaleer wrote:
> > > What is the common practice for using int vs SkScalar?
> > > There was an error that w and h needed to be SkScalar to use the
> canvas->draw
> > > function.
> > > Should I change other int's (like subsetWidth, divisor, extraX etc.) to
> > SkScalar
> > > also?
> > > Only w and h caused an error for being int's, just wondering if using
> SkScalar
> > > is preferred.
> > 
> > not lgtm
> > 
> > int is for when you want an integer. SkScalar is a typdef for float (which
you
> > can find in SkScalar.h). (A little history - SkScalar used to be a fixed
point
> > number instead of floating point. We eventually removed support for SkScalar
> ==
> > SkFixed, and eventually we may make it a double.)
> > 
> > I don't think w and h are the problem. Looking at
> >
>
http://build.chromium.org/p/client.skia.compile/builders/Build-Win-MSVC-x86_6...,
> > it appears that the problem is on line 255, where you call
> > SkCanvas::drawBitmap(subsetBm, x, y), which takes SkScalar parameters. (If
> > you're using an API, you want the type that the API needs.)
> > 
> > We have a macro for converting an int to an SkScalar (again, in SkScalar.h):
> > SkIntToScalar
> 
> >Okay thanks! I now use the SkIntToScalar marco to convert x and y to SkScalar
> when calling drawBitmap

LGTM

[emmaleer, 2015-05-27 19:30:30]

The CQ bit was checked by emmaleer@google.com

[commit-bot: I haz the power, 2015-05-27 19:30:52]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1157153003/80001

[commit-bot: I haz the power, 2015-05-27 19:36:16]

Committed patchset #5 (id:80001) as
https://skia.googlesource.com/skia/+/9700206b67ef2a0aab9a8211c8a901d5123afa9f