1398863 - Resize top sites icons to fill screen, no longer centering with colored background

Status: RESOLVED DUPLICATE of bug 1398970

(Firefox for Android Graveyard :: Awesomescreen, enhancement)

Description

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: Screenshot: japan, Sign in, and github would need to be resized

bbell told me it'd be ideal for top sites icons to be scaled with some resize artifacting, rather than being centered with a colored background (the current behavior). In bug 1388396 comment 12, we decided to try discarding images that were less than 90px (the top sites container is 90dp), which I wrote a patch for. I didn't want to universally change the behavior of favicons used everywhere (what does Gecko do with the favicons?), just for top sites, so I did this only for top sites. However, it turned out to be harder than expected:

(In reply to Michael Comella (:mcomella) from bug 1388396 comment #16)
> The problem is a different bitmap can be cached to disk based on who calls
> first:
> - It won't have a resize cap if AS calls first and will have artifacting,
> even
> when downscaling for history items
> - It'll be capped at 2x scale otherwise, which AS won't show because it's too
> small (when we have a minimum size)
> 
> This resizing bitmap is cached and returned for every other call load in
> icons
> so we get different results in *all* views based on who called first.
> 
> Quick thoughts on solutions:
> - Have separate disk caches based on resizes
> - Cache the original asset, not the resized asset
> - Use the same icon algorithm everywhere wrt resizing & minimum sizes.
> Ideally,
> I think this should be the case but I'm concerned how far reaching this might
> be and that e.g. history icons appear more slow and can take lower resolution
> images

---

In the attached screenshot, "japan", "Sign in...", and "github" would be sites we should resize.

Note that we should not remove the colored background functionality entirely, e.g. for images that are not square.

Break out from bug 1388396.

Comment 1

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Michael Comella (:mcomella) from bug 1388396 comment #19)
> (In reply to Michael Comella (:mcomella) from comment #16)
> > Quick thoughts on solutions:
> > ...
> > - Use the same icon algorithm everywhere wrt resizing & minimum sizes.
> > Ideally,
> > I think this should be the case but I'm concerned how far reaching this might
> > be and that e.g. history icons appear more slow and can take lower resolution
> > images
> 
> I just wrote a patch and the few pages I have in my history don't have
> favicons at 64px+ and appear with generated icons, for example:
> - bugzilla.mozilla.org
> - addons.mozilla.org (a default bookmark)
> - waitbutwhy
> - gmx, a distribution
> - yahoo redirect links
> - blog.bugzilla.com (a vw blog)
> 
> This seems really unfortunate.
> 
> Another (hacky!) solution thought: we can add an activityStreamProcessor
> after the ResizingProcessor which will fall back to generated icons if the
> resized icons are too small. This is hacky because it takes advantage of the
> specific implementation.
> 
> Another thing I noticed: the disk cache doesn't have the resized image but
> the memory cache does.

Comment 2

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Closing in favor of the cleaner explanation bug 1398970.