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:
parent
d518ea7927
commit
5a16cf6545
@ -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);
|
||||
|
Loading…
Reference in New Issue
Block a user