Replace SSE optimization of Color32A_D565

include/core/SkColorPriv.h

Index: include/core/SkColorPriv.h
diff --git a/include/core/SkColorPriv.h b/include/core/SkColorPriv.h
index 9db768783f7d2d1f8775e25ff89fb20bbefcad40..e8edb54ae6bf6bb98c3a9f291cf12f0ec55f02ec 100644
--- a/include/core/SkColorPriv.h
+++ b/include/core/SkColorPriv.h
@@ -281,6 +281,16 @@ static inline U16CPU SkAlphaMulRGB16(U16CPU c, unsigned scale) {
 // this helper explicitly returns a clean 16bit value (but slower)
 #define SkAlphaMulRGB16_ToU16(c, s)  (uint16_t)SkAlphaMulRGB16(c, s)
 
+/** Blend pre-expanded ARGB32 with 16bit color value by the 0..32 scale parameter.
+    The computation yields only 16bits of valid data, but we claim to return
+    32bits, so that the compiler won't generate extra instructions to "clean"
+    the top 16bits.
+*/
+static inline U16CPU SkBlend32A_D565(uint16_t dst, unsigned scale, uint32_t src_expand) {

[reed1, 2015/02/12 14:44:06]

Why is there 32A in the name? Can you pick a name that better reflects the
parameter types? Also, Do functions in this file usually place src first or dst
first?

[henrik.smiding, 2015/02/12 15:45:06]

It was hard to come up with a good name. The method blends an expanded rgb888
color value with a scaled rgb565, and returns rgb565. Would SkBlend32_RGB16 make
more sense? Or SkBlendRGB32_RGB16? But the source isn't in a standard ARGB8888
format either...

Should I move this to BlitRow.h instead? Since it works with a pre-expanded
24-bit color value, to match the SkExpand_rgb_16/SkCompact_rgb_16 above. Not a
common format.

I will change the order of the parameters.

+    uint32_t dst_expand = SkExpand_rgb_16(dst) * scale;
+    return SkCompact_rgb_16((src_expand + dst_expand) >> 5);
+}
+
 /** Blend src and dst 16bit colors by the 0..256 scale parameter.
     The computation yields only 16bits of valid data, but we claim
     to return 32bits, so that the compiler won't generate extra instructions to