SkColorCubeFilter_opts: start with a statically-initializable zero.

SkPMFloat(0) and SkPMFloat(0,0,0,0) end up with the same value,
but the first goes through math to get there.  The second is a lot more
transparent to the compiler, and  should compile all the way down to
just `xorps xmmN,xmmN` or even be optimized away.

Didn't measure any additional benefit from hoisting the zero outside
the loop and writing `SkPMFloat color = zero;`.

Perf win is <2%.

BUG=skia:

Review URL: https://codereview.chromium.org/1314763007

diff --git a/src/opts/SkColorCubeFilter_opts.h b/src/opts/SkColorCubeFilter_opts.h
index a61f66d..41d2525 100644 (file)
--- a/src/opts/SkColorCubeFilter_opts.h
+++ b/src/opts/SkColorCubeFilter_opts.h
@@ -51,7 +51,7 @@ void color_cube_filter_span(const SkPMColor src[],
         const int i10 = (colorToIndex[1][g] + colorToIndex[0][b] * dim) * dim;
         const int i11 = (colorToIndex[1][g] + colorToIndex[1][b] * dim) * dim;
 
-        SkPMFloat color(0);
+        SkPMFloat color(0,0,0,0);
 
         for (int x = 0; x < 2; ++x) {
             const int ix = colorToIndex[x][r];