Add storage and computation of SkColor4f version of gradient stops.
For now, we still only have the SkColor factory, but the Descriptor can
now carry either an SkColor or SkColor4f specified gradient. Base class
constructor automatically populates both forms of color, so that legacy
raster backend will continue to work, and new backend work can operate
directly from the float4 version.
On the GPU side, we have similar logic, but GrGradientEffect only
keeps one version of colors around: SkColor if the destination is
legacy, and SkColor4f (with an optional gamut xform) if the destination
is gamma correct. The 4f colors are already linear, and we gamut xform
them in setData, so gradients are now fully color-correct in sRGB and
F16 modes...
... unless there are more than three stops. Then we use a texture, and
that code path isn't handled yet. We have a few choices here (do we
use an 8-bit sRGB atlas, or just always use F16 linear atlas so we can
share it among both sRGB and wide-gamut rendering). In any case, I'd
like to defer that to a second CL.
This change does fix the non-texture gradients in the gamut GM.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2337313002
Review-Url: https://codereview.chromium.org/2337313002
diff --git a/src/effects/gradients/SkRadialGradient.cpp b/src/effects/gradients/SkRadialGradient.cpp
index 5691188..6eaecff 100644
--- a/src/effects/gradients/SkRadialGradient.cpp
+++ b/src/effects/gradients/SkRadialGradient.cpp
@@ -355,8 +355,11 @@
matrix.postConcat(inv);
}
matrix.postConcat(fPtsToUnit);
+ sk_sp<GrColorSpaceXform> colorSpaceXform = GrColorSpaceXform::Make(fColorSpace.get(),
+ args.fDstColorSpace);
sk_sp<GrFragmentProcessor> inner(GrRadialGradient::Make(
- GrGradientEffect::CreateArgs(args.fContext, this, &matrix, fTileMode)));
+ GrGradientEffect::CreateArgs(args.fContext, this, &matrix, fTileMode,
+ std::move(colorSpaceXform), SkToBool(args.fDstColorSpace))));
return GrFragmentProcessor::MulOutputByInputAlpha(std::move(inner));
}