diff options
author | msarett <msarett@google.com> | 2016-09-14 07:06:08 -0700 |
---|---|---|
committer | Commit bot <commit-bot@chromium.org> | 2016-09-14 07:06:08 -0700 |
commit | 8bbcd5aab81dc0742c3367479c0c9d97363b1203 (patch) | |
tree | bd0b66213561085d1387ae3cb8dd2772184ed580 /src/pathops/SkPathWriter.cpp | |
parent | c20c0c09254a4f77dfa9094a4e820a85e0c8121d (diff) |
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
Diffstat (limited to 'src/pathops/SkPathWriter.cpp')
0 files changed, 0 insertions, 0 deletions