Use proper SkFDot6 instead of int

Use proper SkFDot6 instead of int

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/1c762161d88f0ace8cee1eea43d1b7350c06242e

[qiankun, 2015-03-05 07:38:43]

qiankun.miao@intel.com changed reviewers:
+ reed@google.com

[qiankun, 2015-03-05 07:38:43]

PTAL.

[reed1, 2015-03-05 22:38:48]

Have you run dm locally, to see how this affects drawing?
Is this to fix a visual bug you've seen?

[qiankun, 2015-03-06 09:43:03]

On 2015/03/05 22:38:48, reed1 wrote:
> Have you run dm locally, to see how this affects drawing?
> Is this to fix a visual bug you've seen?

Yes, I run dm locally. A lot of GM failed and need be rebaselined. Also, blink
layout tests need be rebaselined. How to rebase line now? I didn't find previous
ignored-tests.txt file. 

I uploaded a GM to narrow down the issue. It only appears when doing AA. It's
hard for me to see the pixel difference with eyes. Skdiff can capture the
difference.

[qiankun, 2015-03-10 11:07:29]

reed@, could you help to review when you are free?

[reed1, 2015-03-10 14:53:15]

The increase in precision does not seem worth the labor of rebaselining all of
the tests associated with this (in skia and in chrome).

Changing dy to be SkFDot6 would be a nice improvement to document the code (no
runtime change), but the rest we likely will not want to land.

All of that said, I can imagine a modification to your change that keeps the
same number of operations (yours adds 1 extra shift) but also keeps your
increased precision...

fX = FDot6Mul(slope, dy) + (x0 << 10);

where FDot6Mul(a, b) is (a * b >> 6) being careful to avoid overflow on 32bit
ints.

[reed1, 2015-03-10 14:53:25]

reed@google.com changed reviewers:
+ caryclark@google.com

[caryclark, 2015-03-10 15:46:52]

lgtm

[qiankun, 2015-03-11 09:55:29]

On 2015/03/10 14:53:15, reed1 wrote:
> The increase in precision does not seem worth the labor of rebaselining all of
> the tests associated with this (in skia and in chrome).
> 
> Changing dy to be SkFDot6 would be a nice improvement to document the code (no
> runtime change), but the rest we likely will not want to land.
> 
> All of that said, I can imagine a modification to your change that keeps the
> same number of operations (yours adds 1 extra shift) but also keeps your
> increased precision...
> 
> fX = FDot6Mul(slope, dy) + (x0 << 10);
> 
> where FDot6Mul(a, b) is (a * b >> 6) being careful to avoid overflow on 32bit
> ints.

Updated the patch. I can do the rebase-line when you think it's suitable to do
the work in future.

[reed1, 2015-03-11 14:27:14]

This version, which just uses better type names, is fine to land. lgtm

[reed1, 2015-03-11 14:27:35]

There should be no rebaselining needed for this :)

[reed1, 2015-03-11 14:27:39]

The CQ bit was checked by reed@google.com

[reed1, 2015-03-11 14:27:40]

The patchset sent to the CQ was uploaded after l-g-t-m from caryclark@google.com
Link to the patchset: https://codereview.chromium.org/960353005/#ps40001 (title:
"follow comments#6: int->SkFDot6 and remove other code")

[commit-bot: I haz the power, 2015-03-11 14:27:56]

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

[commit-bot: I haz the power, 2015-03-11 18:13:03]

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