Remove sk_linear_to_srgb_noclamp().

We've just re-noticed this can happen:
  1) we have a properly premultiplied linear color;
  2) we convert that to sRGB;
  3) we convert that back to linear;
  4) that color does not appear to be premultiplied.

Removing sk_linear_to_srgb_noclamp(), and thus always clamping to [0,1] here in linear space, does not fix this problem.  However, it does help keep it from propagating too badly.

Just double-checked: the older Sk4f pipeline (SkXfermode4f, SkPM4fPriv, etc) already use sk_linear_to_srgb() exclusively, so they're already doing this same clamp.

BUG=skia:

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

Change-Id: I6352eb0ba969eb25674e8441e43bb51e1e1c0df3
Reviewed-on: https://skia-review.googlesource.com/4314
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>

1 files changed, 4 insertions, 4 deletions

diff --git a/src/opts/SkRasterPipeline_opts.h b/src/opts/SkRasterPipeline_opts.h
index 950264efb1..bd42632b4b 100644
--- a/src/opts/SkRasterPipeline_opts.h
+++ b/src/opts/SkRasterPipeline_opts.h
@@ -405,10 +405,10 @@ STAGE(load_s_srgb, true) {
 
 STAGE(store_srgb, false) {
     auto ptr = *(uint32_t**)ctx + x;
-    store<kIsTail>(tail, (      sk_linear_to_srgb_noclamp(r) << SK_R32_SHIFT
-                         |      sk_linear_to_srgb_noclamp(g) << SK_G32_SHIFT
-                         |      sk_linear_to_srgb_noclamp(b) << SK_B32_SHIFT
-                         | SkNx_cast<int>(255.0f * a + 0.5f) << SK_A32_SHIFT ), (int*)ptr);
+    store<kIsTail>(tail, (              sk_linear_to_srgb(r) << SK_R32_SHIFT
+                         |              sk_linear_to_srgb(g) << SK_G32_SHIFT
+                         |              sk_linear_to_srgb(b) << SK_B32_SHIFT
+                         | SkNx_cast<int>(0.5f + 255.0f * a) << SK_A32_SHIFT), (int*)ptr);
 }
 
 RGBA_XFERMODE(clear)    { return 0.0f; }