Add luminance mask transfer modes.

include/effects/SkLumaXfermode.h

Index: include/effects/SkLumaXfermode.h
diff --git a/include/effects/SkLumaXfermode.h b/include/effects/SkLumaXfermode.h
new file mode 100644
index 0000000000000000000000000000000000000000..b64c94d63fe1ba0d0b2f54f1195a971c54976021
--- /dev/null
+++ b/include/effects/SkLumaXfermode.h
@@ -0,0 +1,53 @@
+/*
+ * Copyright 2013 Google Inc.
+ *
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+#ifndef SkLumaXfermode_DEFINED
+#define SkLumaXfermode_DEFINED
+
+#include "SkXfermode.h"
+
+/**
+ *  Luminance mask transfer, as defined in
+ *  http://www.w3.org/TR/SVG/masking.html#Masking
+ *  http://www.w3.org/TR/css-masking/#MaskValues
+ *
+ *  The luminance-to-alpha function is applied before performing a standard
+ *  SrcIn or DstIn xfer:

[reed1, 2013/08/22 18:35:51]

Is this list (srcin, dstin) complete, or just e.g. ?

[f(malita), 2013/08/22 19:25:52]

It is complete with regard to SVG/CSS masking support. I did consider the more
general approach of wrapping arbitrary transfer modes, but decided to avoid it
initially for two reasons:

1) unclear semantics - for masking (SrcIn, DstOut) the luma operand is clearly
defined (the one with a zero color transfer coefficient); for arbitrary modes,
we would need a way to specify which of the inputs needs to be luma-transformed.

2) efficiency - conditionally applying luma to one/both operands and invoking
arbitrary mode procs in the transfer loop is possibly significantly slower than
the current inlined implementation. I don't have hard numbers though, so this
concern may be unwarranted.

Both of these are solvable/tolerable, but what tipped the balance for me was the
lack of a good use case for anything other than srcin/dst out - it's unclear
whether any of the other resulting transfer functions make sense/have any
practical use. I could certainly be convinced otherwise :)

+ *
+ *    luma(C) = (0.2125 * C.r + 0.7154 * C.g + 0.0721 * C.b) * C.a

[reed1, 2013/08/22 18:35:51]

Can you document what happens to the resulting r,g,b?

[f(malita), 2013/08/22 19:25:52]

Will do.

+ *
+ *  The only supported submodes are SrcIn and DstIn.
+ */
+class SK_API SkLumaMaskXfermode : public SkXfermode {
+public:
+    static SkXfermode* Create(SkXfermode::Mode);

[reed1, 2013/08/22 18:35:51]

Should you support another Create that takes SkXfermode* instead of an enum?

[f(malita), 2013/08/22 19:25:52]

This ties into the decision to support arbitrary transfer modes. We can
certainly do that if needed, but we'll need a more flexible API and will
possibly take a perf hit.

+
+    virtual SkPMColor xferColor(SkPMColor, SkPMColor) const SK_OVERRIDE;
+    virtual void xfer32(SkPMColor dst[], const SkPMColor src[], int count,
+                        const SkAlpha aa[]) const SK_OVERRIDE;
+
+    SK_DEVELOPER_TO_STRING()
+    SK_DECLARE_PUBLIC_FLATTENABLE_DESERIALIZATION_PROCS(SkLumaMaskXfermode)
+
+#if SK_SUPPORT_GPU
+    virtual bool asNewEffectOrCoeff(GrContext*, GrEffectRef**, Coeff*, Coeff*,
+                                    GrTexture*) const SK_OVERRIDE;
+#endif
+
+protected:
+    SkLumaMaskXfermode(SkFlattenableReadBuffer&);
+    virtual void flatten(SkFlattenableWriteBuffer&) const SK_OVERRIDE;
+
+private:
+    SkLumaMaskXfermode(SkXfermode::Mode);
+
+    const SkXfermode::Mode fMode;
+
+    typedef SkXfermode INHERITED;
+};
+
+#endif