Convert Color32 code to perfect blend.

Convert Color32 code to perfect blend.

Before we commit to blend_256_round_alt, let's make sure blend_perfect is
really slower in practice (i.e. regresses on perf.skia.org).

blend_perfect is really the most desirable algorithm if we can afford it.  Not
only is it correct, but it's easy to think about and break into correct pieces:
for instance, its div255() doesn't require any coordination with the multiply.

This looks like a 30% hit according to microbenches.  That said, microbenches
said my previous change would be a 20-25% perf improvement, but it didn't end
up showing a significant effect at a high level.

As for correctness, I see a bunch of off-by-1 compared to blend_256_round_alt
(exactly what we'd expect), and one off-by-3 in a GM that looks like it has a
bunch of overdraw.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/61221e7f87a99765b0e034020e06bb018e2a08c2

[mtklein_C, 2015-04-20 16:19:26]

mtklein@chromium.org changed reviewers:
+ fmalita@chromium.org, reed@chromium.org

[mtklein_C, 2015-04-20 16:19:39]

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

[mtklein_C, 2015-04-20 16:19:47]

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

[commit-bot: I haz the power, 2015-04-20 16:19:58]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1098913002/100001

[commit-bot: I haz the power, 2015-04-20 16:27:00]

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

[commit-bot: I haz the power, 2015-04-20 16:27:01]

Dry run: This issue passed the CQ dry run.

[mtklein, 2015-04-20 17:39:10]

mtklein@google.com changed reviewers:
+ mtklein@google.com

[mtklein, 2015-04-20 17:39:11]

https://perf.skia.org/#3238 plots the geometric mean of 8888 SKP runs over time.
 Just wanted to post this to point out how much of a no-op that original CL was
on overall performance... it's hard to even find.

[mtklein, 2015-04-20 17:51:49]

I'm going to land this before review so that the perf and test bots can get
chewing on it.

[mtklein, 2015-04-20 17:51:54]

The CQ bit was checked by mtklein@google.com

[mtklein, 2015-04-20 17:51:55]

lgtm

[commit-bot: I haz the power, 2015-04-20 17:52:18]

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

[commit-bot: I haz the power, 2015-04-20 17:52:32]

Committed patchset #6 (id:100001) as
https://skia.googlesource.com/skia/+/61221e7f87a99765b0e034020e06bb018e2a08c2

[reed1, 2015-04-20 18:53:33]

I am nervous with such a large perf hit, even if it is *only* in a micro-bench
at the moment. Speeding up sometimes means lots of edge-case speedups that get
accumulated (the reverse of 1000 cuts).

[mtklein, 2015-04-20 19:05:21]

So far, with most but not all bots reporting in, I see no downside to switching
to a perfect blend: https://perf.skia.org/#3239  (top line is arithmetic mean,
bottom is geometric mean, smaller is better, this CL is currently 2nd from the
right).

I'm starting to think this is a situation where we've got CPU to burn in
practice that we don't have in a microbenchmark setting.  That is, if the
microbenchmark fits in cache level N, and the real world only in cache level
N+1, we now have latency(N+1) - latency(N) free CPU cycles.

[reed1, 2015-04-20 19:10:29]

Hmmm, if we assume SKPs are the only measure of our library and its performance.

I posit that we can write a <canvas> animation/game that would care a lot about
blending speed.

Anyway, I'm fine we're doing the experiment, but I'm still finding it hard to
"fix" something I can't really see and take a perf hit at the same time.

[mtklein, 2015-04-20 22:15:11]

On 2015/04/20 19:10:29, reed1 wrote:
> Hmmm, if we assume SKPs are the only measure of our library and its
performance.
> 
> I posit that we can write a <canvas> animation/game that would care a lot
about
> blending speed.
> 
> Anyway, I'm fine we're doing the experiment, but I'm still finding it hard to
> "fix" something I can't really see and take a perf hit at the same time.

Hmm.  I agree we do have a problem here.

After profiling this a bit more, I think I understand why Color32's performance
doesn't matter much to Blink's SKPs.
These profiles are extremely regular:
  - zillions of rects, mostly with an opaque color
  - lots of text
  - some bitmaps, sometimes scaled
  - other stuff in small doses

Color32 is the number one hot spot, but >90% of the time spent there is just
devolved into sk_memset32 for opaque colors.  The hottest interesting code is
SkARGB32_A8_BlitMask_SSE2, almost entirely for text.

This is analysis is nothing new of course.  But it's reminded me that it may be
time for us to retrace the strategic direction we'd like to go with for
performance.  We seem to be optimized for and actively optimizing for scenarios
we're not testing.  That's either because we don't have adequate coverage of
real-world use of Skia, or because we've optimized for things that are not very
important in real-world use.

I have many ideas about possible directions we could take, but I don't want to
freak you out by listing them all here.

[mtklein, 2015-04-21 15:09:15]

A revert of this CL (patchset #6 id:100001) has been created in
https://codereview.chromium.org/1083923006/ by mtklein@google.com.

The reason for reverting is: Xfermode_SrcOver not looking encouraging.  Up to
50% regressions.

https://perf.skia.org/#3242.