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>
37155d476c