blimp: Reduce WebP encoding time on the engine.

blimp/engine/renderer/engine_image_serialization_processor.cc

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "blimp/engine/renderer/engine_image_serialization_processor.h"
 
 #include <stddef.h>
 #include <vector>
 
 #include "base/logging.h"
@@ skipping 49 matching lines @@
     std::vector<unsigned char> data;
     picture.custom_ptr = &data;
 
     // Use our own WebPWriterFunction implementation.
     picture.writer = &WebPImageEncoder::WriteOutput;
 
     // Setup the configuration for the output WebP picture. This is currently
     // the same as the default configuration for WebP, but since any change in
     // the WebP defaults would invalidate all caches they are hard coded.
     config.quality = 75.0;  // between 0 (smallest file) and 100 (biggest).
-    config.method = 4;  // quality/speed trade-off (0=fast, 6=slower-better).
+    config.method = 0;  // quality/speed trade-off (0=fast, 6=slower-better).

[nyquist, 2016/04/14 17:19:30]

I discussed this with urvang@ in patch set 5 of
https://codereview.chromium.org/1680333004/#ps80001
(blimp/common/compositor/blimp_image_serialization_processor.cc). He suggested
sticking to the standards for these unless we have very good reasons for why
not.

How much does this CL change the time it takes to encode?
I guess if we in the future push this off to a different thread, it wouldn't
matter as much what the quality is then, so maybe you could add a TODO about
investigating this again when we make the whole image serialization and sending
async?

urvang@: Do you have any thoughts around what would be a fast, but still OK
quality method for this?

[urvang, 2016/04/14 17:41:16]

I understand that this is a temporary solution before you make sending of images
not part of the critical path.

In this case, looks fine for now. Add TODOs to:
- Change the value of 'config.method' later. I think a value of 3 or 4 (default)
should work later.
- Investigate if it's feasible to enable multithreading inside libwebp aka
"config.thread_level = 1"

[Khushal, 2016/04/14 18:46:24]

Thanks for the suggestion Urvang. I tried using multi-threading by setting the
thread_level to 1 but it didn't cause a significant difference, only in the
order of a few microseconds. The method change alone is of great help.

 
     // Encode the picture using the given configuration.
     bool success = WebPEncode(&config, &picture);
 
     // Release the memory allocated by WebPPictureImport*(). This does not free
     // the memory used by the picture object itself.
     WebPPictureFree(&picture);
 
     if (!success)
       return nullptr;
@@ skipping 79 matching lines @@
   return pixel_serializer_.get();
 }
 
 SkPicture::InstallPixelRefProc
 EngineImageSerializationProcessor::GetPixelDeserializer() {
   return nullptr;
 }
 
 }  // namespace engine
 }  // namespace blimp