Index: src/codec/SkSwizzler.cpp |
diff --git a/src/codec/SkSwizzler.cpp b/src/codec/SkSwizzler.cpp |
index f9f212072e53e4bb2565e87aadb6fdff0213c1e6..133736879f203e53e5962dab4a4530ad3f5f93f7 100644 |
--- a/src/codec/SkSwizzler.cpp |
+++ b/src/codec/SkSwizzler.cpp |
@@ -929,15 +929,17 @@ SkSwizzler::SkSwizzler(RowProc fastProc, RowProc proc, const SkPMColor* ctable, |
{} |
int SkSwizzler::onSetSampleX(int sampleX) { |
- SkASSERT(sampleX > 0); // Surely there is an upper limit? Should there be |
msarett
2016/02/10 13:42:59
I don't think there is an upper limit. If they as
scroggo
2016/02/10 16:06:09
sgtm
|
- // way to report failure? |
+ SkASSERT(sampleX > 0); |
+ |
fSampleX = sampleX; |
fSrcOffsetUnits = (get_start_coord(sampleX) + fSrcOffset) * fSrcBPP; |
fDstOffsetBytes = (fDstOffset / sampleX) * fDstBPP; |
fSwizzleWidth = get_scaled_dimension(fSrcWidth, sampleX); |
fAllocatedWidth = get_scaled_dimension(fDstWidth, sampleX); |
- // The optimized swizzler routines do not (yet) support sampling. |
+ // The optimized swizzler functions do not support sampling. Sampled swizzles |
+ // are already fast because they skip pixels. We haven't seen a situation |
+ // where speeding up sampling has a significant impact on total decode time. |
if (1 == fSampleX && fFastProc) { |
fActualProc = fFastProc; |
} else { |