blimp: Reduce WebP encoding time on the engine.

blimp/engine/renderer/engine_image_serialization_processor.cc

Index: blimp/engine/renderer/engine_image_serialization_processor.cc
diff --git a/blimp/engine/renderer/engine_image_serialization_processor.cc b/blimp/engine/renderer/engine_image_serialization_processor.cc
index 8d1f2bb5f05310f481cd3fab66ac312ee8da584a..3e6aad72a3bcdc69ec15686d51f5888785d52df3 100644
--- a/blimp/engine/renderer/engine_image_serialization_processor.cc
+++ b/blimp/engine/renderer/engine_image_serialization_processor.cc
@@ -67,7 +67,7 @@ class WebPImageEncoder : public SkPixelSerializer {
     // 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);