GrConstColorProcessor uses 4f colors in the destination space

Many places that construct one are explicitly specifying opaque white or
transparent black, which we can assume (based on the semantics of the
operation) should remain (0,0,0,0) or (1,1,1,1), so that's simple.

In other cases, we convert our source color to destination space.

One wrinkle is tht SkColorFilter now needs to know the destination color
space, due to SkModeColorFilter.

BUG=skia:

GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3903

Change-Id: I4969c0260588f4021300733f601b47dc606adf79
Reviewed-on: https://skia-review.googlesource.com/3903
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>

1 files changed, 2 insertions, 1 deletions

diff --git a/src/effects/SkColorCubeFilter.cpp b/src/effects/SkColorCubeFilter.cpp
index 3eb70d32d0..2a921d8e50 100644
--- a/src/effects/SkColorCubeFilter.cpp
+++ b/src/effects/SkColorCubeFilter.cpp
@@ -298,7 +298,8 @@ void GrColorCubeEffect::GLSLProcessor::GenKey(const GrProcessor& proc,
                                               const GrGLSLCaps&, GrProcessorKeyBuilder* b) {
 }
 
-sk_sp<GrFragmentProcessor> SkColorCubeFilter::asFragmentProcessor(GrContext* context) const {
+sk_sp<GrFragmentProcessor> SkColorCubeFilter::asFragmentProcessor(GrContext* context,
+                                                                  SkColorSpace*) const {
     static const GrUniqueKey::Domain kDomain = GrUniqueKey::GenerateDomain();
     GrUniqueKey key;
     GrUniqueKey::Builder builder(&key, kDomain, 2);