Set desired_image_size when decoding images for NTP Tile icons.

chrome/browser/search/suggestions/image_decoder_impl.h

Index: chrome/browser/search/suggestions/image_decoder_impl.h
diff --git a/chrome/browser/search/suggestions/image_decoder_impl.h b/chrome/browser/search/suggestions/image_decoder_impl.h
index 658b7c4fcaa79ffe6b343716739917ac5cccecf0..3e21eb59fb85300882b3e36ce72273ce437d1c37 100644
--- a/chrome/browser/search/suggestions/image_decoder_impl.h
+++ b/chrome/browser/search/suggestions/image_decoder_impl.h
@@ -21,6 +21,7 @@ class ImageDecoderImpl : public image_fetcher::ImageDecoder {
 
   void DecodeImage(
       const std::string& image_data,
+      const gfx::Size& desired_image_frame_size,
       const image_fetcher::ImageDecodedCallback& callback) override;

[Marc Treib, 2017/03/01 09:17:26]

Hm, one high-level comment: This returns a gfx::Image, which has support for
multiple sizes. If that's possible, it might be nicer (API-wise) to simply
decode all of them. WDYT?

[tschumann, 2017/03/01 09:37:43]

I totally agree -- just that's how the whole image decoding stack works :-)

If there's a place where we need multiple versions of the image, we should
follow up. Right now, I don't have a clear use case. Plus, that's a much larger
change. 

Let's fix the concrete issue here, and then get the larger discussion started.

[Marc Treib, 2017/03/01 09:41:56]

I think in terms of API, it would actually be a smaller change: no need to pass
the gfx::Size around everywhere. Just on the lowest level, we'd decode all
available frames.

But probably, an API that allows to request a specific size is useful anyway, so
I'm okay with this too.

[tschumann, 2017/03/01 11:36:36]

I agree. I'm mostly concerned about changing semantics though and regressions --
given how many parties use this API. If we have a strong use case, I'm
absolutely willing to push that idea forward (just as a separate effort).

 
  private: