Move all knowledge of X sampling into SkScaledCodec

src/codec/SkBmpRLECodec.cpp

Index: src/codec/SkBmpRLECodec.cpp
diff --git a/src/codec/SkBmpRLECodec.cpp b/src/codec/SkBmpRLECodec.cpp
index e76a23ed14ad78ac93f9bd6b73a24ce69beb6f31..5896601012c28aefeb3549d00370bf4978781f07 100644
--- a/src/codec/SkBmpRLECodec.cpp
+++ b/src/codec/SkBmpRLECodec.cpp
@@ -43,6 +43,8 @@ SkCodec::Result SkBmpRLECodec::onGetPixels(const SkImageInfo& dstInfo,
         // Subsets are not supported.
         return kUnimplemented;
     }
+    // FIXME: This may be my misunderstanding of this class, but it seems like
+    // scaling could be supported?

[msarett, 2015/10/01 19:34:33]

Yes sampling in the x dimension is already implemented.  We could consider
implementing sampling in the y dimension so that this class supports scaling
natively.

I'm still not quite sure that this is best though.

[scroggo, 2015/10/01 21:16:57]

What do you think is the right way to handle it? In my patch, RLE will no longer
work with SkScaledCodec, which has to be able get a sampler to update. If this
class handles sampling itself, we don't need to worry about that.

[msarett, 2015/10/01 22:53:06]

I haven't given this enough thought yet.

In my mind, it would be ideal for SkScaledCodec to handle it, but I'm in favor
of doing it natively if its more efficient to do it natively (which it is, based
on the ideas we've discussed so far).

     if (dstInfo.dimensions() != this->getInfo().dimensions()) {
         SkCodecPrintf("Error: scaling not supported.\n");
         return kInvalidScale;
@@ -269,7 +271,8 @@ SkCodec::Result SkBmpRLECodec::prepareToDecode(const SkImageInfo& dstInfo,
         return SkCodec::kInvalidConversion;
     }
 
-    SkScaledCodec::ComputeSampleSize(dstInfo, this->getInfo(), &fSampleX, NULL);
+    SkScaledCodec::ComputeSampleSize(dstInfo.dimensions(), this->getInfo().dimensions(),
+                                     &fSampleX, NULL);
 
     return SkCodec::kSuccess;
 }