aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/core/Sk4px.h
diff options
context:
space:
mode:
authorGravatar mtklein <mtklein@chromium.org>2016-01-08 11:45:21 -0800
committerGravatar Commit bot <commit-bot@chromium.org>2016-01-08 11:45:21 -0800
commitdefa0daa6a0f4e97a3527a522ae602c6771a7c80 (patch)
tree1d47593806af59cc46dd58a40e99e3b27e2c55ad /src/core/Sk4px.h
parent1a1efeacf7cc94a8c2977114dfe230fed3efc105 (diff)
Clean up SkXfermode_opts.h
It seems that MSVC + __vectorcall don't play well together, so back ourselves out into a situation where we don't need it. - Inline transfermode functions. This removes the need for SK_VECTORCALL. - Remove 565 destination specializations. Blending into 565 is not speed-critical enough to merit the code bloat. - Removing 565 specializations means a bunch of Sk4px code is now dead. 8888 xfermodes generally speed up a bit from inlining, smoothly ranging from no change down to 0.65x for the fastest functions like Plus or Modulate. 565 xfermodes generally slow down because we're doing 565 -> 8888 and 8888->565 conversion serially[1] and using the stack, smoothly ranging from no change up to 2x slower for the fastest functions like Plus and Modulate. [1] the 565->8888 conversion is actually being autovectorized BUG=skia:4765,skia:4776 GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1565223002 CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot No public API changes. TBR=reed@google.com Review URL: https://codereview.chromium.org/1565223002
Diffstat (limited to 'src/core/Sk4px.h')
-rw-r--r--src/core/Sk4px.h24
1 files changed, 8 insertions, 16 deletions
diff --git a/src/core/Sk4px.h b/src/core/Sk4px.h
index 3755488a4a..05378a8bc8 100644
--- a/src/core/Sk4px.h
+++ b/src/core/Sk4px.h
@@ -48,14 +48,6 @@ public:
void store2(SkPMColor[2]) const;
void store1(SkPMColor[1]) const;
- // Same as above for 565.
- static Sk4px Load4(const SkPMColor16 src[4]);
- static Sk4px Load2(const SkPMColor16 src[2]);
- static Sk4px Load1(const SkPMColor16 src[1]);
- void store4(SkPMColor16 dst[4]) const;
- void store2(SkPMColor16 dst[2]) const;
- void store1(SkPMColor16 dst[1]) const;
-
// 1, 2, or 4 SkPMColors with 16-bit components.
// This is most useful as the result of a multiply, e.g. from mulWiden().
class Wide : public Sk16h {
@@ -105,8 +97,8 @@ public:
// A generic driver that maps fn over a src array into a dst array.
// fn should take an Sk4px (4 src pixels) and return an Sk4px (4 dst pixels).
- template <typename Fn, typename Dst>
- static void MapSrc(int n, Dst* dst, const SkPMColor* src, const Fn& fn) {
+ template <typename Fn>
+ static void MapSrc(int n, SkPMColor* dst, const SkPMColor* src, const Fn& fn) {
SkASSERT(dst);
SkASSERT(src);
// This looks a bit odd, but it helps loop-invariant hoisting across different calls to fn.
@@ -137,8 +129,8 @@ public:
}
// As above, but with dst4' = fn(dst4, src4).
- template <typename Fn, typename Dst>
- static void MapDstSrc(int n, Dst* dst, const SkPMColor* src, const Fn& fn) {
+ template <typename Fn>
+ static void MapDstSrc(int n, SkPMColor* dst, const SkPMColor* src, const Fn& fn) {
SkASSERT(dst);
SkASSERT(src);
while (n > 0) {
@@ -167,8 +159,8 @@ public:
}
// As above, but with dst4' = fn(dst4, alpha4).
- template <typename Fn, typename Dst>
- static void MapDstAlpha(int n, Dst* dst, const SkAlpha* a, const Fn& fn) {
+ template <typename Fn>
+ static void MapDstAlpha(int n, SkPMColor* dst, const SkAlpha* a, const Fn& fn) {
SkASSERT(dst);
SkASSERT(a);
while (n > 0) {
@@ -197,8 +189,8 @@ public:
}
// As above, but with dst4' = fn(dst4, src4, alpha4).
- template <typename Fn, typename Dst>
- static void MapDstSrcAlpha(int n, Dst* dst, const SkPMColor* src, const SkAlpha* a,
+ template <typename Fn>
+ static void MapDstSrcAlpha(int n, SkPMColor* dst, const SkPMColor* src, const SkAlpha* a,
const Fn& fn) {
SkASSERT(dst);
SkASSERT(src);