Local salient image storage for enhanced bookmark experiment.

components/bookmarks_enhanced/image_store_util_android.cc

Index: components/bookmarks_enhanced/image_store_util_android.cc
diff --git a/components/bookmarks_enhanced/image_store_util_android.cc b/components/bookmarks_enhanced/image_store_util_android.cc
new file mode 100644
index 0000000000000000000000000000000000000000..e0f9775aff49b958d78cc93589b59a1d2e0868fa
--- /dev/null
+++ b/components/bookmarks_enhanced/image_store_util_android.cc
@@ -0,0 +1,17 @@
+// Copyright 2014 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 "components/bookmarks_enhanced/image_store_util.h"
+
+namespace image_store_util {
+
+scoped_refptr<base::RefCountedMemory> BytesForImage(gfx::Image image) {
+  return image.As1xPNGBytes();

[sky, 2014/05/06 16:14:20]

How come you only store the 1x image? Shouldn't you store all the image reps?

[Kibeom Kim (inactive), 2014/05/07 09:56:30]

I thought about it. Since this is a local image cache, I think it's sufficient
to store one image scale that's closest to the current device dpi. I'll add
Image::AsPNGBytes(float desired_scale); function.

[sky, 2014/05/07 16:25:30]

Might a particular platform end up with more than one scale? I know this can
happen on chromeos if you switch to a projector. That said, I haven't seen where
you're getting the images from. If your source only ever provides one scale then
there is no point in dealing with multiple (DCHECK).

[Kibeom Kim (inactive), 2014/05/08 00:02:19]

ptal.

Yes actually, on Android, we'll be feeding images from BitmapFetcher, and we're
not dealing with multiple scales. I added DCHECK.

Also I changed to use jpeg.

+}
+
+gfx::Image ImageForBytes(const scoped_refptr<base::RefCountedMemory>& bytes) {
+  return gfx::Image::CreateFrom1xPNGBytes(bytes->front(), bytes->size());
+}
+
+}