Normalize SkXfermode_opts.h argument order as d,s[,aa].

At head they're s,d[,aa] in SkXfermode_opts.h but Sk4px::Map* expect d,s[,aa]
so we ended up having to write weird little lambda shims to match impedance.

There's no reason for these to disagree, and d,s[,aa] is the One True Order
(because no matter what you're doing in graphics, there's always a dst).

Should be no perf or image diff, though I'm suspicious it might help MSVC code generation.

BUG=skia:4117

Committed: https://skia.googlesource.com/skia/+/6028a8476504022fe40b6870b1460b5e4a80969f

CQ_EXTRA_TRYBOTS=client.skia:Test-Win8-MSVC-ShuttleB-CPU-AVX2-x86-Release-Trybot

Review URL: https://codereview.chromium.org/1289903002
This commit is contained in:
mtklein 2015-08-13 13:10:30 -07:00 committed by Commit bot
parent d518ea7927
commit 5a16cf6545

View File

@ -110,7 +110,7 @@ XFERMODE(Lighten) {
#undef XFERMODE
// Some xfermodes use math like divide or sqrt that's best done in floats 1 pixel at a time.
#define XFERMODE(Name) static SkPMFloat SK_VECTORCALL Name(SkPMFloat s, SkPMFloat d)
#define XFERMODE(Name) static SkPMFloat SK_VECTORCALL Name(SkPMFloat d, SkPMFloat s)
XFERMODE(ColorDodge) {
auto sa = s.alphas(),
@ -257,13 +257,13 @@ public:
private:
inline SkPMColor xfer32(SkPMColor dst, SkPMColor src) const {
return fProcF(SkPMFloat(src), SkPMFloat(dst)).round();
return fProcF(SkPMFloat(dst), SkPMFloat(src)).round();
}
inline SkPMColor xfer32(SkPMColor dst, SkPMColor src, SkAlpha aa) const {
SkPMFloat s(src),
d(dst),
b(fProcF(s,d));
b(fProcF(d,s));
// We do aa in full float precision before going back down to bytes, because we can!
SkPMFloat a = Sk4f(aa) * Sk4f(1.0f/255);
b = b*a + d*(Sk4f(1)-a);