SkColorSpace_ICC: classify two entry tables as linear

The bug linked in this CL was caused by the switch to SkJumper -
where we decided to stop interpolating table-lookups.

In this case, the image has tables with two entries: 0, 1.

This fixes the bug by optimizing away the table lookup for
these trivial no-op tables.  I think this is a good change
on its own.  We see these tables fairly regularly.

A more robust fix would expand "small" tables into larger
ones through interpolation.  Should we also do this?

Bug: 722855
Change-Id: I3881734c6f28b5519cbe593dd05cc7b6b1b8a9d0
Reviewed-on: https://skia-review.googlesource.com/17272
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>

1 files changed, 10 insertions, 0 deletions

diff --git a/src/core/SkColorSpace_ICC.cpp b/src/core/SkColorSpace_ICC.cpp
index 52196091fe..5a510903c6 100644
--- a/src/core/SkColorSpace_ICC.cpp
+++ b/src/core/SkColorSpace_ICC.cpp
@@ -327,6 +327,16 @@ static SkGammas::Type parse_gamma(SkGammas::Data* outData, SkColorSpaceTransferF
                 return set_gamma_value(outData, value);
             }
 
+            // This optimization is especially important for A2B profiles, where we do
+            // not resize tables or interpolate lookups.
+            if (2 == count) {
+                if (0 == read_big_endian_u16((const uint8_t*) &table[0]) &&
+                        65535 == read_big_endian_u16((const uint8_t*) &table[1])) {
+                    outData->fNamed = kLinear_SkGammaNamed;
+                    return SkGammas::Type::kNamed_Type;
+                }
+            }
+
             // Check for frequently occurring sRGB curves.
             // We do this by sampling a few values and see if they match our expectation.
             // A more robust solution would be to compare each value in this curve against