Is this done now?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a2796c212636511499f47597e76865d7577cd1c8

commit a2796c212636511499f47597e76865d7577cd1c8
Author: nyquist <nyquist@chromium.org>
Date: Mon Apr 18 20:58:17 2016

Initial version of Blimp BlobCache.

Currently, every time there is a commit from engine to client, all
pictures are sent again, leading to poor performance and high
bandwidth usage.

This CL adds a cache on the client side that never clears out any
received resources. This means that the engine can depend on that
the client has all resources it has previously sent, and uses this fact
to only send down a unique identifier (SHA1 hash of the image) and the
the width and height in place of the image itself. This is wrapped in
the new proto BlobCacheImageMetadata. If this would be a new image for
the client, the proto also includes the payload of the image. This
payload will be removed when the BlobChannel is fully integrated.

The identifier is calculated based on the source image, to ensure that
no encode is required on the engine when the same image is seen again.

To ensure that the cache is used for all images, this changes the
behavior of the serializer to also encode images that were previously
encoded as WebP, to ensure that they become cacheable.

BUG= 597807 ,  600719 ,  603353 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review URL: https://codereview.chromium.org/1867653002

Cr-Commit-Position: refs/heads/master@{#388013}

[modify] https://crrev.com/a2796c212636511499f47597e76865d7577cd1c8/blimp/client/feature/compositor/decoding_image_generator.cc
[modify] https://crrev.com/a2796c212636511499f47597e76865d7577cd1c8/blimp/common/BUILD.gn
[add] https://crrev.com/a2796c212636511499f47597e76865d7577cd1c8/blimp/common/blob_cache/blob_cache.h
[add] https://crrev.com/a2796c212636511499f47597e76865d7577cd1c8/blimp/common/blob_cache/id_util.cc
[add] https://crrev.com/a2796c212636511499f47597e76865d7577cd1c8/blimp/common/blob_cache/id_util.h
[add] https://crrev.com/a2796c212636511499f47597e76865d7577cd1c8/blimp/common/blob_cache/in_memory_blob_cache.cc
[add] https://crrev.com/a2796c212636511499f47597e76865d7577cd1c8/blimp/common/blob_cache/in_memory_blob_cache.h
[add] https://crrev.com/a2796c212636511499f47597e76865d7577cd1c8/blimp/common/blob_cache/in_memory_blob_cache_unittest.cc
[modify] https://crrev.com/a2796c212636511499f47597e76865d7577cd1c8/blimp/common/compositor/webp_decoder.cc
[modify] https://crrev.com/a2796c212636511499f47597e76865d7577cd1c8/blimp/common/proto/BUILD.gn
[add] https://crrev.com/a2796c212636511499f47597e76865d7577cd1c8/blimp/common/proto/blob_cache.proto
[modify] https://crrev.com/a2796c212636511499f47597e76865d7577cd1c8/blimp/engine/BUILD.gn
[modify] https://crrev.com/a2796c212636511499f47597e76865d7577cd1c8/blimp/engine/renderer/engine_image_serialization_processor.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5344a6eebfbd65e6a86f2274c69e74ac6ccfe138

commit 5344a6eebfbd65e6a86f2274c69e74ac6ccfe138
Author: nyquist <nyquist@chromium.org>
Date: Mon Apr 25 23:29:24 2016

[blimp] Change to use SHA-256 instead of SHA-1 for unique ids

Blimp currently uses SHA-1 to uniquely identify resources. There was
no specific reason for this other than the goal of having a unique
ID, so this changes it to instead use SHA-256 from //crypto, since it
is in general better. This does however change the length of the
hash from 20 bytes to 32 bytes.

This concern was raised as a drive-by comment on
https://codereview.chromium.org/1867653002/

This CL also adds functionality to verify that a specific BlobId has
the correct length, and removes all references to SHA1 outside of
the //blimp/common/blob_cache/id_util.[cc|h] files.

In addition, this CL adds a test to ensure that there is certainty
that this unique ID only ever changes intentionally.

BUG= 597807 ,  600719 ,  603353 

Review URL: https://codereview.chromium.org/1912153004

Cr-Commit-Position: refs/heads/master@{#389608}

[modify] https://crrev.com/5344a6eebfbd65e6a86f2274c69e74ac6ccfe138/blimp/common/BUILD.gn
[modify] https://crrev.com/5344a6eebfbd65e6a86f2274c69e74ac6ccfe138/blimp/common/DEPS
[modify] https://crrev.com/5344a6eebfbd65e6a86f2274c69e74ac6ccfe138/blimp/common/blob_cache/id_util.cc
[modify] https://crrev.com/5344a6eebfbd65e6a86f2274c69e74ac6ccfe138/blimp/common/blob_cache/id_util.h
[add] https://crrev.com/5344a6eebfbd65e6a86f2274c69e74ac6ccfe138/blimp/common/blob_cache/id_util_unittest.cc
[modify] https://crrev.com/5344a6eebfbd65e6a86f2274c69e74ac6ccfe138/blimp/common/blob_cache/in_memory_blob_cache.cc
[modify] https://crrev.com/5344a6eebfbd65e6a86f2274c69e74ac6ccfe138/blimp/common/compositor/webp_decoder.cc
[modify] https://crrev.com/5344a6eebfbd65e6a86f2274c69e74ac6ccfe138/blimp/engine/renderer/engine_image_serialization_processor.cc

Tracking disk-cache version in a new bug.

Disk-based cache tracked in  issue 611584 .