diff options
author | mtklein <mtklein@chromium.org> | 2015-06-26 10:46:31 -0700 |
---|---|---|
committer | Commit bot <commit-bot@chromium.org> | 2015-06-26 10:46:31 -0700 |
commit | 2aab22a58a366df4752c1cf0f004092c6e7be335 (patch) | |
tree | bc4026ca98f28068b99ca6394c05a0129f0dc4d6 /tests/DataRefTest.cpp | |
parent | cdb42bb55c3bdbbd6682dcd50b5c77322bb6e565 (diff) |
Color dodge and burn with SkPMFloat.
Both 25-35% faster with SSE.
With NEON, Burn measures as a ~10% regression, Dodge a huge 2.9x improvement.
The Burn regression is somewhat artificial: we're drawing random colored rects onto an opaque white dst, so we're heavily biased toward the (d==da) fast path in the serial code. In the vector code there's no short-circuiting and we always pay a fixed cost for ColorBurn regardless of src or dst content.
Dodge's fast paths, in contrast, only trigger when (s==sa) or (d==0), neither of which happens any more than randomly in our benchmark. I don't think (d==0) should happen at all. Similarly, the (s==0) Burn fast path is really only going to happen as often as SkRandom allows.
In practice, the existing Burn benchmark is hitting its fast path 100% of the time. So I actually feel really great that this only dings the benchmark by 10%.
Chrome's still guarded by SK_SUPPORT_LEGACY_XFERMODES, which I'll lift after finishing the last xfermode, SoftLight.
BUG=skia:
Review URL: https://codereview.chromium.org/1214443002
Diffstat (limited to 'tests/DataRefTest.cpp')
0 files changed, 0 insertions, 0 deletions