Add timing SkCodec to nanobench.

bench/CodecBench.cpp

Index: bench/CodecBench.cpp
diff --git a/bench/CodecBench.cpp b/bench/CodecBench.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..18de5ae1e9c0ab4e42034371a2843ffdeb577f10
--- /dev/null
+++ b/bench/CodecBench.cpp
@@ -0,0 +1,66 @@
+/*
+ * Copyright 2015 Google Inc.
+ *
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+#include "CodecBench.h"
+#include "SkBitmap.h"
+#include "SkCodec.h"
+#include "SkData.h"
+#include "SkImageGenerator.h"
+#include "SkOSFile.h"
+#include "SkStream.h"
+
+CodecBench::CodecBench(SkString baseName, SkData* encoded, SkColorType colorType)
+    : fColorType(colorType)
+    , fStream(new SkMemoryStream(encoded))
+{
+    // Parse filename and the color type to give the benchmark a useful name
+    const char* colorName;
+    switch(colorType) {
+        case kN32_SkColorType:
+            colorName = "N32";
+            break;
+        case kRGB_565_SkColorType:
+            colorName = "565";
+            break;
+        case kAlpha_8_SkColorType:
+            colorName = "Alpha8";
+            break;
+        default:
+            colorName = "Unknown";
+    }
+    fName.printf("Codec_%s_%s", baseName.c_str(), colorName);
+#ifdef SK_DEBUG

[mtklein, 2015/04/01 15:17:22]

Seems fine in Release too.

[scroggo, 2015/04/01 17:18:04]

Sure. Just unnecessary, since we do not actually do anything with codec after
this (since SkASSERT is defined to nothing in release).

Not sure if the compiler will give a warning that we do not use codec after
instantiating.

+    // Ensure that we can create an SkCodec from this stream.
+    SkAutoTDelete<SkCodec> codec(SkCodec::NewFromStream(fStream->duplicate()));
+    SkASSERT(codec);
+#endif
+}
+
+const char* CodecBench::onGetName() {
+    return fName.c_str();
+}
+
+bool CodecBench::isSuitableFor(Backend backend) {
+    return kNonRendering_Backend == backend;
+}
+
+void CodecBench::onDraw(const int n, SkCanvas* canvas) {
+    SkBitmap bitmap;
+    SkAutoTDelete<SkCodec> codec;
+    for (int i = 0; i < n; i++) {
+        // We need to create a duplicate of fStream since SkCodec takes
+        // ownership
+        codec.reset(SkCodec::NewFromStream(fStream->duplicate()));

[msarett, 2015/04/01 14:44:36]

It's unfortunate that we have to duplicate the stream.  How much do you think
that duplicating the stream will dilute the timing of the decode?  Maybe this
isn't a big deal, and if we really care, we can do some sort of profiling on the
bench to see how much time is actually spent in the decode?

Would another option be to only loop once and call detach() instead of
duplicate()?  Can nanobench accurately time a very short bench and/or run a
single bench many times and take the average?

[scroggo, 2015/04/01 14:59:49]

My guess would be not much. For an SkMemoryStream, we basically do three things:
- call new
- ref the SkData
- initialize fOffset to 0 (and fData to the original)
I suspect it's not a big deal, but if we're comparing against SkImageDecoder,
which I think is the meaningful comparison (at least for now), it will also pay
the price of duplication.
My limited understanding of nanobench is that it figures out the best number of
times to loop. Looping only once would seem to defeat that.

[mtklein, 2015/04/01 15:17:22]

Think things look more clearly cheap if we use SkCodec::NewFromData()?  Seems
like less code too.  Or are we explicitly concerned with benching
NewFromStream()?

[scroggo, 2015/04/01 17:18:04]

NewFromData calls NewFromStream, so I don't think that would make a big
difference. That said, it might be more clear to store an SkData here?

[mtklein, 2015/04/01 17:22:19]

Yeah, seems like it, if only because the nanobench-facing API talks in terms of
SkData.

[scroggo, 2015/04/01 17:40:53]

Done.

+        bitmap.allocPixels(codec->getInfo());

[mtklein, 2015/04/01 15:17:22]

Unless you need this to make a fair apples-to-apples comparison, I'd do this
outside the loop, or override onPreDraw() and do it there?

[scroggo, 2015/04/01 17:18:04]

Yes, this makes it a more fair comparison. Come to think of it, though, we could
move it outside of the loop and make SkImageDecoder use a custom allocator which
uses preallocated memory. Then we can compare both decodes without worrying
about allocation.

Done, in the latest patch.

+#ifdef SK_DEBUG
+        const SkImageGenerator::Result result =
+#endif
+        codec->getPixels(bitmap.info(), bitmap.getPixels(), bitmap.rowBytes());
+        SkASSERT(result == SkImageGenerator::kSuccess
+                 || result == SkImageGenerator::kIncompleteInput);
+    }
+}