Templatize SkPMFloat to support both 1 and 255 biases.

Templatize SkPMFloat to support both 1 and 255 biases.

We used to use a 255 bias.  It was fast to convert up and down, but weird to
multiply (must remember to /255) and is just generally weird to think about.

We now use a 1 bias.  That's a multiply slower on each side of SkPMColor
conversion, but makes future multiplies cheaper, and is easier to think about.

I think there a places where both are valuable, particularly in code where
we can either isolate the div 255 weirdness to one or two spots, or in code
that involves no component multiplication at all.  Most code stays <1>.

PS2 is about a 15% speedup for the "colorcube" bench on my x86 desktop,
and about a 10% speedup on my ARMv7 Nexus 7 Mk.2.

The <255> roundtrip bench runs about 20% faster than the <1> bench on my
desktop, and about 30% faster on that N7.

No GM or SKP pixels change on my desktop.

BUG=skia:4117

[mtklein_C, 2015-08-27 15:57:57]

The CQ bit was checked by mtklein@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-08-27 15:58:03]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308903003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308903003/20001

[mtklein_C, 2015-08-27 16:06:11]

The CQ bit was checked by mtklein@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-08-27 16:06:20]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308903003/40002
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308903003/40002

[mtklein_C, 2015-08-27 16:09:46]

mtklein@chromium.org changed reviewers:
+ noel@chromium.org, reed@google.com

[commit-bot: I haz the power, 2015-08-27 16:11:52]

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

[commit-bot: I haz the power, 2015-08-27 16:11:53]

Dry run: This issue passed the CQ dry run.

[reed1, 2015-08-27 16:34:42]

https://codereview.chromium.org/1308903003/diff/40002/src/effects/SkColorMatr...
File src/effects/SkColorMatrixFilter.cpp (right):

https://codereview.chromium.org/1308903003/diff/40002/src/effects/SkColorMatr...
src/effects/SkColorMatrixFilter.cpp:243: float scale = SkPMFloat<1>(x).a();
Hmmm, these use-cases are interesting / confusion.

I have x, which contains 4 floats
I want access to the one that "means" alpha
I must specify the bias, just to extract it as a float? It is a little bit of a
surprise.

[mtklein_C, 2015-08-27 17:07:40]

https://codereview.chromium.org/1308903003/diff/40002/src/effects/SkColorMatr...
File src/effects/SkColorMatrixFilter.cpp (right):

https://codereview.chromium.org/1308903003/diff/40002/src/effects/SkColorMatr...
src/effects/SkColorMatrixFilter.cpp:243: float scale = SkPMFloat<1>(x).a();
On 2015/08/27 16:34:42, reed1 wrote:
> Hmmm, these use-cases are interesting / confusion.
> 
> I have x, which contains 4 floats
> I want access to the one that "means" alpha
> I must specify the bias, just to extract it as a float? It is a little bit of
a
> surprise.

Yep, pretty much.  They're two distinct types now, though in this case the two
constructors that take Sk4f are mechanically identical, so I can see the
confusion.  Imagine there were a call to this->validate() at the end of the
constructor... the bias defines the type.

You can also just write this directly to get the alpha if it makes more sense to
you:
    float scale = x.kth<SK_A32_SHIFT/8>()

Think this indicates we've coupled together being in SkPMColor order and staying
in range too hard?

[Noel Gordon, 2015-08-31 01:12:17]

Perf-wise, I measured mac air 131ms -> 104ms, Dell win7 151ms -> 125ms

[Noel Gordon, 2015-08-31 12:36:37]

On 2015/08/31 01:12:17, noel gordon wrote:
> Perf-wise, I measured mac air 131ms -> 104ms, Dell win7 151ms -> 125ms

Similar results on hp z620 win7.

[mtklein, 2015-08-31 13:39:36]

On 2015/08/31 12:36:37, noel gordon wrote:
> On 2015/08/31 01:12:17, noel gordon wrote:
> > Perf-wise, I measured mac air 131ms -> 104ms, Dell win7 151ms -> 125ms
> 
> Similar results on hp z620 win7.

Sweet.

Been letting this roll around in the back of my head this weekend.  I think I
can make things simpler, clearer and faster (i.e. both Mikes and Noel all happy)
by collapsing some of the Sk4f / SkPMFloat abstraction.  I'll leave this here
and start a new CL, and hopefully that new CL obsoletes this one.