Update XPF invariant info to not account for conflation

src/gpu/effects/GrCoverageSetOpXP.cpp

Index: src/gpu/effects/GrCoverageSetOpXP.cpp
diff --git a/src/gpu/effects/GrCoverageSetOpXP.cpp b/src/gpu/effects/GrCoverageSetOpXP.cpp
index 92a5c689a65d5acbf4fbf81238ea0357d8fc44e6..99809562a863c70caf9636dc12add20542480db2 100644
--- a/src/gpu/effects/GrCoverageSetOpXP.cpp
+++ b/src/gpu/effects/GrCoverageSetOpXP.cpp
@@ -230,21 +230,21 @@ GrCoverageSetOpXPFactory::onCreateXferProcessor(const GrCaps& caps,
     return CoverageSetOpXP::Create(fRegionOp, fInvertCoverage);
 }
 
-void GrCoverageSetOpXPFactory::getInvariantOutput(const GrProcOptInfo& colorPOI,
-                                                  const GrProcOptInfo& coveragePOI,
-                                                  GrXPFactory::InvariantOutput* output) const {
+void GrCoverageSetOpXPFactory::getInvariantBlendedColor(const GrProcOptInfo& /*colorPOI*/,

[bsalomon, 2015/06/02 13:44:33]

Shouldn't need to comment out the param name. We only do that in public headers
because of a warning generated in a client's build system (Android I believe). I
kind of prefer not to have the clutter if we don't need it.

[egdaniel, 2015/06/02 14:19:41]

Does this guy really make sense in this new BlendedColor world? I feel like
coveragePOI should no longer be part of this check and it is the only thing this
guy is looking at.

[Chris Dalton, 2015/06/02 16:06:06]

My sense is that it does make sense, because this XP is writing the coverage
value as if it were a legitimate color output (this differs from the other XPs
that only use coverage to antialias the real color). All the current
optimizations in skia are relevant for this XP based on what it's returning
here.

That being said, I definitely agree it's unfortunate to include the coveragePOI
as a parameter this function now. A couple alternatives I can think of:

1) Remove coveragePOI from the arg list like you suggest. We can still set
fWillBlendWithDst in here, and the only optimization that looks at the known
color anyway is "clear instead of drawRect", which seems irrelevant since
GrClipMaskManager calls clear directly.

2) Rework this XP to use the color input instead. GrClipMaskManager would be
responsible to make sure the info comes in through that channel instead of the
coverage input.

Thinking about it some more, #1 seems pretty good...

[egdaniel, 2015/06/02 16:46:54]

So my vote would be for option 1. As you said we can still set fWillBelndWithDst
to true or false the same as before. However my main reason for not caring if we
"lose" optimizations here is that running through all our gm's, we never call
getInvariantOutput with a setCoverageOptXPF. So if we aren't using it ever, then
we should have a worse signature to support it. At least this is my opinion.

[Chris Dalton, 2015/06/02 17:07:12]

Agreed. Done.

+                                                        const GrProcOptInfo& coveragePOI,
+                                                        InvariantBlendedColor* blendedColor) const {
     if (SkRegion::kReplace_Op == fRegionOp) {
         if (coveragePOI.isSolidWhite()) {
-            output->fBlendedColor = GrColor_WHITE;
-            output->fBlendedColorFlags = kRGBA_GrColorComponentFlags;
+            blendedColor->fKnownColor = GrColor_WHITE;
+            blendedColor->fKnownColorFlags = kRGBA_GrColorComponentFlags;
         } else {
-            output->fBlendedColorFlags = 0;
+            blendedColor->fKnownColorFlags = kNone_GrColorComponentFlags;
         }
 
-        output->fWillBlendWithDst = false;
+        blendedColor->fWillBlendWithDst = false;
     } else {
-        output->fBlendedColorFlags = 0;
-        output->fWillBlendWithDst = true;
+        blendedColor->fKnownColorFlags = kNone_GrColorComponentFlags;
+        blendedColor->fWillBlendWithDst = true;
     }
 }