aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/pathops/SkPathOpsCurve.cpp
diff options
context:
space:
mode:
authorGravatar msarett <msarett@google.com>2016-09-14 07:06:08 -0700
committerGravatar Commit bot <commit-bot@chromium.org>2016-09-14 07:06:08 -0700
commit8bbcd5aab81dc0742c3367479c0c9d97363b1203 (patch)
treebd0b66213561085d1387ae3cb8dd2772184ed580 /src/pathops/SkPathOpsCurve.cpp
parentc20c0c09254a4f77dfa9094a4e820a85e0c8121d (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/SkPathOpsCurve.cpp')
0 files changed, 0 insertions, 0 deletions