Rework out-of-gamut handling in SkRasterPipeline

Instead of trying to carefully manage the in-gamut / out-of-gamut state
of the pipeline, let's do what a GPU would do, clamping to representable
range in any float -> integer conversion.

Most effects doing table lookups now clamp themselves internally, and
the store_foo() methods clamp when the destination is fixed point.  In
turn the from_srgb() conversions and all future transfer function stages
can care less about this stuff.

If I'm thinking right, the _lowp side of things need not change at all,
and that will soften the performance impact of this change.  Anything
that was fast to begin with was probably running a _lowp pipeline.

Bug: skia:7419

Change-Id: Id2e080ac240a97b900a1ac131c85d9e15f70af32
Reviewed-on: https://skia-review.googlesource.com/85740
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>

1 files changed, 0 insertions, 7 deletions

diff --git a/src/effects/SkTableColorFilter.cpp b/src/effects/SkTableColorFilter.cpp
index 75ffbd6190..1d506256f5 100644
--- a/src/effects/SkTableColorFilter.cpp
+++ b/src/effects/SkTableColorFilter.cpp
@@ -113,13 +113,6 @@ public:
         if (fFlags & kG_Flag) { g = ptr; ptr += 256; }
         if (fFlags & kB_Flag) { b = ptr;             }
 
-        // If our inputs are out of range, we'd attempt to read values outside our tables.
-        // We could finesse this with p->clamp_if_unclamped(kPremul_SkAlphaType) here, but
-        // this filter is already slow enough that I'd rather just be paranoid and safe.
-        p->append(SkRasterPipeline::clamp_0);
-        p->append(SkRasterPipeline::clamp_a);
-        p->set_clamped(true);
-
         if (!shaderIsOpaque) {
             p->append(SkRasterPipeline::unpremul);
         }