Save large icons to a new LARGE_ICON type

components/favicon_base/favicon_types.h

 // 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.
 
 #ifndef COMPONENTS_FAVICON_BASE_FAVICON_TYPES_H_
 #define COMPONENTS_FAVICON_BASE_FAVICON_TYPES_H_
 
 #include "base/memory/ref_counted_memory.h"
 #include "base/memory/scoped_ptr.h"
 #include "ui/gfx/geometry/size.h"
 #include "ui/gfx/image/image.h"
 #include "url/gurl.h"
 
 namespace favicon_base {
 
 struct FallbackIconStyle;
 
 typedef int64 FaviconID;
 
 // Defines the icon types. They are also stored in icon_type field of favicons
 // table.
+//
 // The values of the IconTypes are used to select the priority in which favicon
 // data is returned in HistoryBackend and ThumbnailDatabase. Data for the
 // largest IconType takes priority if data for multiple IconTypes is available.
+//
+// Note that LARGE_ICON is a virtual icon type. In desktop environments, where
+// favicons are small by default and larger touch icons are not the norm, it
+// denotes the largest icon determined to be available. The underlying icon may
+// have originated as a large FAVICON, a TOUCH_PRECOMPOSED_ICON, or a
+// TOUCH_ICON. In mobile environments, larger sized icons are generally captured
+// by default, so additional LARGE_ICON tagged icons are not stored. The
+// LARGE_ICON type tag is only applied at the storage and query layers; icons
+// are recognized using their true underlying type and, if it is determined that
+// a large icon is desired but will not otherwise be captured, the backend
+// selects the best candidate and saves it using the LARGE_ICON type. When
+// querying for a large icon, all potential icon types are considered and the
+// returned results are evaluted based on the requested size.
 enum IconType {
   INVALID_ICON = 0x0,
   FAVICON = 1 << 0,
   TOUCH_ICON = 1 << 1,
-  TOUCH_PRECOMPOSED_ICON = 1 << 2
+  TOUCH_PRECOMPOSED_ICON = 1 << 2,
+  LARGE_ICON = 1 << 3

[sky, 2015/05/06 19:50:42]

Why do we need the new type?

[Roger McFarlane (Chromium), 2015/05/06 21:22:51]

The way the url-to-icon mappings are managed causes multiple representations of
the same IconType to step all over one another.

For example, if there two link-rel-icon entries in an html file one for 16x16
and one for 192x192, both get mapped to the FAVICON type in the DB. Say the
16x16 gets inserted first. When the 192x192 gets mapped, there is no good way to
determine whether or not it should replace the 16x16 or be added alongside it.
They both claim to be the FAVICON for the page.

The current mapping update logic causes the 16x16 would be unmapped and deleted.

 };
 
 // Defines a gfx::Image of size desired_size_in_dip composed of image
 // representations for each of the desired scale factors.
 struct FaviconImageResult {
   FaviconImageResult();
   ~FaviconImageResult();
 
   // The resulting image.
   gfx::Image image;
@@ skipping 51 matching lines @@
   FaviconRawBitmapResult bitmap;
 
   // The fallback icon style if a sufficiently large icon isn't available. This
   // uses the dominant color of a smaller icon as the background if available.
   scoped_ptr<FallbackIconStyle> fallback_icon_style;
 };
 
 }  // namespace favicon_base
 
 #endif  // COMPONENTS_FAVICON_BASE_FAVICON_TYPES_H_