DM testing for skipping and scaling

dm/DM.cpp

Index: dm/DM.cpp
diff --git a/dm/DM.cpp b/dm/DM.cpp
index 55563fef08997dcf08f941c733577e51d3103ff6..76799da11ef183e66bf887fc7c2f4f8ab806b400 100644
--- a/dm/DM.cpp
+++ b/dm/DM.cpp
@@ -203,25 +203,37 @@ static void push_codec_srcs(Path path) {
         return;
     }
 
+    // Choose scales for scaling tests
+    const float scales[] = { 0.125f, 0.25f, 0.5f, 1.0f, 2.0f, 4.0f };

[scroggo, 2015/06/11 15:50:02]

It looks we'll use 1.0f twice - once in kScale_Mode and once in kNormal_Mode
(oh, and a third time in kScanline_Mode, although that may make sense...) Is
this intentional? Do we do something interestingly different in kScale_Mode with
1.0f?

Also, I'm not sure that scaling up is interesting. We can always allow the
drawing code to scale up. The really interesting part is scaling down, when we
can save memory (and potentially go faster).

How did you choose the downscales? If we want to compare with SkImageDecoder, we
should choose scales that can be used by it. We should perhaps do some that
require the fallback path as well.

[msarett, 2015/06/11 19:29:35]

In the new design, scale is not a mode.  Rather, each mode will be tested for
all of the input scales.

I agree that scaling up is not interesting.  These have been removed.

The downscales are known to work well with the current scaling implementation
for jpeg (powers of 2).  These are also integer downscales, so they will be able
to be compared to scaling on SkImageDecoder (when we implement a scaling test
for SkImageDecoder).

More scales can (and should) be added once our scaling capabilities are
expanded.  To my knowledge, only JpegCodec (powers of 2) and IcoCodec (depends
on which images are embedded) support scaling.

+
     // Build additional test cases for images that decode natively to non-canvas types
     switch(codec->getInfo().colorType()) {
         case kGray_8_SkColorType:
             push_src("image", "codec_kGray8", new CodecSrc(path, CodecSrc::kNormal_Mode,
-                    CodecSrc::kGrayscale_Always_DstColorType));
+                    CodecSrc::kGrayscale_Always_DstColorType, 1.0f));
             push_src("image", "scanline_kGray8", new CodecSrc(path, CodecSrc::kScanline_Mode,
-                    CodecSrc::kGrayscale_Always_DstColorType));
+                    CodecSrc::kGrayscale_Always_DstColorType, 1.0f));
             push_src("image", "scanline_subset_kGray8", new CodecSrc(path,
-                    CodecSrc::kScanline_Subset_Mode, CodecSrc::kGrayscale_Always_DstColorType));
+                    CodecSrc::kScanline_Subset_Mode, CodecSrc::kGrayscale_Always_DstColorType,
+                    1.0f));
+            for (float scale : scales) {
+                push_src("image", "scale_kGray8", new CodecSrc(path, CodecSrc::kScale_Mode,
+                        CodecSrc::kGrayscale_Always_DstColorType, scale));
+            }
             // Intentional fall through
             // FIXME: Is this a long term solution for testing wbmps decodes to kIndex8?
             // Further discussion on this topic is at skbug.com/3683
         case kIndex_8_SkColorType:
             push_src("image", "codec_kIndex8", new CodecSrc(path, CodecSrc::kNormal_Mode,
-                    CodecSrc::kIndex8_Always_DstColorType));
+                    CodecSrc::kIndex8_Always_DstColorType, 1.0f));
             push_src("image", "scanline_kIndex8", new CodecSrc(path, CodecSrc::kScanline_Mode,
-                    CodecSrc::kIndex8_Always_DstColorType));
+                    CodecSrc::kIndex8_Always_DstColorType, 1.0f));
             push_src("image", "scanline_subset_kIndex8", new CodecSrc(path,
-                    CodecSrc::kScanline_Subset_Mode, CodecSrc::kIndex8_Always_DstColorType));
+                    CodecSrc::kScanline_Subset_Mode, CodecSrc::kIndex8_Always_DstColorType, 1.0f));
+            for (float scale : scales) {
+                push_src("image", "scale_kIndex8", new CodecSrc(path, CodecSrc::kScale_Mode,
+                        CodecSrc::kIndex8_Always_DstColorType, scale));
+            }
             break;
         default:
             // Do nothing
@@ -230,11 +242,15 @@ static void push_codec_srcs(Path path) {
 
     // Decode all images to the canvas color type
     push_src("image", "codec", new CodecSrc(path, CodecSrc::kNormal_Mode,
-            CodecSrc::kGetFromCanvas_DstColorType));
+            CodecSrc::kGetFromCanvas_DstColorType, 1.0f));
     push_src("image", "scanline", new CodecSrc(path, CodecSrc::kScanline_Mode,

[scroggo, 2015/06/11 15:50:02]

I could imagine that it might be useful to test scanline mode with a scale. (At
least in the case where the decoder supports it; if we have to fallback when the
decoder does not, I think we'll be using the scanline decoder anyway.)

[msarett, 2015/06/11 19:29:35]

I agree.  The new patch tests scaling for all of the modes.  As far as
fallbacks, we are choosing not to test the cases where onGetScaledDimensions
fails to scale and returns the original dimensions.

As we discussed, in the case that this occurs, the long term plan is to use the
scanline decoder to implement scaling.  I think how we might test this
capability will become more clear once we have a better idea of the
implementation plan.

-            CodecSrc::kGetFromCanvas_DstColorType));
+            CodecSrc::kGetFromCanvas_DstColorType, 1.0f));
     push_src("image", "scanline_subset", new CodecSrc(path, CodecSrc::kScanline_Subset_Mode,
-            CodecSrc::kGetFromCanvas_DstColorType));
+            CodecSrc::kGetFromCanvas_DstColorType, 1.0f));
+    for (float scale : scales) {
+        push_src("image", "scale", new CodecSrc(path, CodecSrc::kScale_Mode,
+                CodecSrc::kGetFromCanvas_DstColorType, scale));
+    }
 }
 
 static bool codec_supported(const char* ext) {