Reduce overhead for linear color xforms
authormsarett <msarett@google.com>
Wed, 14 Sep 2016 14:06:08 +0000 (07:06 -0700)
committerCommit bot <commit-bot@chromium.org>
Wed, 14 Sep 2016 14:06:08 +0000 (07:06 -0700)
commit8bbcd5aab81dc0742c3367479c0c9d97363b1203
treebd0b66213561085d1387ae3cb8dd2772184ed580
parentc20c0c09254a4f77dfa9094a4e820a85e0c8121d
Reduce overhead for linear color xforms

We used to build src and dst transfer fn tables
every time a new xform was created with linear
src and dst.  Now we don't compute them because
we don't need them.

This will make SkColorSpaceXform a far better
option for any xforms with float or half-float
inputs or outputs, particularly on a small number
of pixels.

This CL also moves SkColorSpaceXform closer to
what I anticipate will be the eventual 'API design'.
I think apply() will want to take a SrcColorType enum
(not created yet because it's not necessary yet) and
a DstColorType enum (still using SkColorType because
there's not yet a reason not to).

Performance changes:
toSRGB  341us -> 366us
to2Dot2 404us -> 403us
toF16   318us -> 304us

There's no reason for toSRGB or to2Dot2 to change.
The refactor seems to have caused the compiler to
order the instructions a little differently...
This is something to come back to if we need to
squeeze more performance out of sRGB.  For now,
let's not be held up by something we don't control.

F16 likely improves because we are no longer
(unnecessarily) building the linear tables.

Code size gets a little bigger.  Measuring
SkColorSpaceXform size as a percentage of src/ size,
we go from 0.8% to 1.4%.

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

Review-Url: https://codereview.chromium.org/2335723002
bench/ColorCodecBench.cpp
src/core/SkColorSpaceXform.cpp
src/core/SkColorSpaceXform.h