Revert of Implement four more xfermodes with Sk4px. (patchset #16 id:290001 of https...
authormtklein <mtklein@google.com>
Wed, 24 Jun 2015 21:30:43 +0000 (14:30 -0700)
committerCommit bot <commit-bot@chromium.org>
Wed, 24 Jun 2015 21:30:43 +0000 (14:30 -0700)
commit0cc1f0a8d5ed69c76d75061bc2dee3b1d0ce0605
treef3978f17559721a0e69c556d975d057986678e70
parentb9d4163bebab0f5639f9c5928bb5fc15f472dddc
Revert of Implement four more xfermodes with Sk4px. (patchset #16 id:290001 of https://codereview.chromium.org/1196713004/)

Reason for revert:
64-bit ARM build failures.

Original issue's description:
> Implement four more xfermodes with Sk4px.
>
> HardLight, Overlay, Darken, and Lighten are all
> ~2x faster with SSE, ~25% faster with NEON.
>
> This covers all previously-implemented NEON xfermodes.
> 3 previous SSE xfermodes remain.  Those need division
> and sqrt, so I'm planning on using SkPMFloat for them.
> It'll help the readability and NEON speed if I move that
> into [0,1] space first.
>
> The main new concept here is c.thenElse(t,e), which behaves like
> (c ? t : e) except, of course, both t and e are evaluated.  This allows
> us to emulate conditionals with vectors.
>
> This also removes the concept of SkNb.  Instead of a standalone bool
> vector, each SkNi or SkNf will just return their own types for
> comparisons.  Turns out to be a lot more manageable this way.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/b9d4163bebab0f5639f9c5928bb5fc15f472dddc

TBR=reed@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Review URL: https://codereview.chromium.org/1205703008
src/core/Sk4px.h
src/core/Sk4pxXfermode.h
src/core/SkNx.h
src/opts/SkNx_neon.h
src/opts/SkNx_sse.h
src/opts/SkXfermode_opts_SSE2.cpp
src/opts/SkXfermode_opts_arm_neon.cpp