Make ImageDecodeBench build once again

third_party/WebKit/Source/web/ImageDecodeBench.cpp

Index: third_party/WebKit/Source/web/ImageDecodeBench.cpp
diff --git a/third_party/WebKit/Source/web/ImageDecodeBench.cpp b/third_party/WebKit/Source/web/ImageDecodeBench.cpp
index b0738bb999a298d8e4892256a5ae295eed61b5be..51487e2db0240631d16f67ac5f4f8f112114a5f6 100644
--- a/third_party/WebKit/Source/web/ImageDecodeBench.cpp
+++ b/third_party/WebKit/Source/web/ImageDecodeBench.cpp
@@ -280,10 +280,10 @@ bool decodeImageData(SharedBuffer* data, bool colorCorrection, size_t packetSize
     }
 
     RefPtr<SharedBuffer> packetData = SharedBuffer::create();
-    unsigned position = 0;
+    size_t position = 0;
     while (true) {
         const char* packet;
-        unsigned length = data->getSomeData(packet, position);
+        size_t length = data->getSomeData(packet, position);
 
         length = std::min(static_cast<size_t>(length), packetSize);
         packetData->append(packet, length);
@@ -368,7 +368,8 @@ int main(int argc, char* argv[])
     // Set image decoding Platform options.
 

[Noel Gordon, 2016/04/26 14:09:59]

Maybe a DeferredImageDecoder::setEnabled(false); is needed here to disable
deferred decoding?  An alternative option might be to just preroll the SkImage
of a frame?

[scroggo_chromium, 2016/04/29 13:44:30]

I don't see how this is necessary. That only affects using DeferredImageDecoder,
which this program does not use. It uses ImageDecoder directly, which will never
accidentally use deferred.

(That line used to be in here, but you removed it in
https://chromium.googlesource.com/chromium/src/+/d6e97a9d13f0adc2a31432136f83...)

[Noel Gordon, 2016/05/02 12:31:09]

I recall in testing the older code last week, that the color profile initializer
in ImageFrame was being called twice, but called only once if I called
DeferredImageDecoder::setEnabled(false) during setup.

Maybe doesn't matter anymore now you have done an initial decode and thrown the
result away.

 #if USE(QCMSLIB)
-    ImageDecoder::qcmsOutputDeviceProfile(); // Initialize screen colorProfile.
+    // FIXME: This method has been removed, but it is important.

[ccameron, 2016/04/21 07:30:42]

Could you give a bit more detail about what is "important"?

I suspect this impacts the benchmark because the first call to
qcmsOutputDeviceProfile() will do a blocking IPC to the browser process, which
is an artifact that you don't want to appear in your timing data.

If so, a couple of options:

First, below, in the 
  for (size_t i = 0; i < iterations; ++i) {
you could change that to go through iterations+1 and just toss out the i=0
result. This is probably something you'll want to do anyway.

Second, we had some discussion earlier about adding a more predictable and
controllable mechanism for communicating device color profiles. We could
continue in that direction, and specify the output color profile to a specific
color profile there: https://codereview.chromium.org/1796293003/

We should probably do both of these. The first to lower variance. The second
because we probably don't want the machine's system settings (its monitor color
profile) to be impacting this benchmark.

[scroggo_chromium, 2016/04/29 13:44:30]

As I understand it, the question is not whether the tool is important, but
whether this call is important. noel@, you know more about this method than I
do, but based on the comment, it looks like it did some initialization outside
of the loop, so we don't factor it into the time.
Done.

[Noel Gordon, 2016/05/02 12:31:09]

Yeap, that's right, to remove profile initialization effects from the results. 
Doing an initial decode outside the loop, as you have done now, should remove
any initialization effects too, I expect.

+    // ImageDecoder::qcmsOutputDeviceProfile(); // Initialize screen colorProfile.
 #endif
 
     // Read entire file content to data.