Refactored-out the code of thumbnaling algorithm from thumbnail_tab_helper.

chrome/browser/thumbnails/thumbnailing_algorithm.h

+// Copyright (c) 2013 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.
+
+#ifndef CHROME_BROWSER_THUMBNAILS_THUMBNAILING_ALGORITHM_H_
+#define CHROME_BROWSER_THUMBNAILS_THUMBNAILING_ALGORITHM_H_
+
+#include "base/memory/ref_counted.h"
+#include "chrome/browser/thumbnails/thumbnailing_context.h"
+#include "ui/gfx/rect.h"
+#include "ui/gfx/size.h"
+
+class SkBitmap;
+
+namespace thumbnails {
+
+// An interface abstracting thumbnailing algorithms. Instances are intended to
+// be created by ThumbnailService's implementations and used by
+// ThumbnailTabHelper as consumers of captured source images.
+class ThumbnailingAlgorithm
+    : public base::RefCountedThreadSafe<ThumbnailingAlgorithm> {

[sky, 2013/01/17 20:18:36]

Why is this ref counted thread safe?

[motek., 2013/01/18 18:38:41]

The new algorithm(s) will be more costly than the current one. The idea is to
have the option to shunt parts of thumbnail cropping to another thread.

[sky, 2013/01/18 21:43:26]

Why does that mean they need to be ref counted? Isn't there a single clean owner
here?

[motek., 2013/01/18 22:56:52]

Ah, I see what you mean. 'Need' is not the best word here. It clearly can be
either owned or one-time use. However, I still believe we would be better off
having ThumbnailingAlgorithm as a disposable refcounted entity. Here are my
reasons:

1. I think the only reasonable owner would be ThumbnailService.
2. ThumbnailService itself is refcounted so in principle it could go away. Thus,
passing methods of an entity *it* owns bound as callbacks would be as
problematic. I would like to be able to do it, it generally results in less
boilerplate.
3. For implementing the new algo (GaussianGradientThumbnailCrop, in works) I
would like to keep intermediate data in the instance. To this end, having a
single use entity would be very convenient. If I make it 'owned', it will have
to be stateless with all methods const-ed.

In summary, I think that such design gives me considerable flexibility (up to
employing more then one algorithm if we need different thumbnails for different
purposes) at no cost. 

+ public:
+  typedef base::Callback<void(ThumbnailingContext*, const SkBitmap&)>
+      ConsumerCallback;
+  // Provides information necessary to crop-and-resize image data from a source
+  // canvas of |source_size|. Auxiliary |scale_factor| helps compute the target
+  // thumbnail size. Parameters of the required copy operation are assigned to
+  // |clipping_rect| (cropping rectangle for the source canvas) and
+  // |target_size| (the size of the target bitmap).
+  // The return value indicates the type of clipping that will be done.
+  virtual ClipResult GetCanvasCopyInfo(const gfx::Size& source_size,
+                                       ui::ScaleFactor scale_factor,
+                                       gfx::Rect* clipping_rect,
+                                       gfx::Size* target_size) const = 0;
+
+  // Invoked to produce a thumbnail image from a |bitmap| extracted by the
+  // callee from source canvas according to instructions provided by a call
+  // to GetCanvasCopyInfo.
+  // Note that ProcessBitmap must be able to handle bitmaps which might have not
+  // been processed (scalled/cropped) as requested. |context| gives additional
+  // information on the source, including if and how it was clipped.
+  // The function shall invoke |callback| once done, passing in fully populated
+  // |context| along with resulting thumbnail bitmap.
+  virtual void ProcessBitmap(ThumbnailingContext* context,
+                             const SkBitmap& bitmap,
+                             const ConsumerCallback& callback) = 0;
+
+ protected:
+  virtual ~ThumbnailingAlgorithm() {}
+  friend class base::RefCountedThreadSafe<ThumbnailingAlgorithm>;
+};
+
+}
+
+#endif  // CHROME_BROWSER_THUMBNAILS_THUMBNAILING_ALGORITHM_H_