Closed Bug 708197 Opened 13 years ago Closed 12 years ago

Load top site thumbnails asynchronously in native about:home

Categories

(Firefox for Android Graveyard :: General, defect, P4)

All
Android
defect

Tracking

(blocking-fennec1.0 -)

RESOLVED DUPLICATE of bug 785945
Tracking Status
blocking-fennec1.0 --- -

People

(Reporter: dougt, Assigned: lucasr)

References

Details

(Whiteboard: startup, startup-ux)

I see AwesomeCursorViewBinder.updateImage called seven times on the main thread before Gecko is loaded.  This accounts for about 3% of startup.
The current about:home code doesn't limit the number of thumbnails. So, depending on the number of bookmarks you have, the number of updateImage() calls might be even higher. In the new design though (see bug 706667) we only show up to 4 thumbnails.

Each updateImage() call involves decoding the image stored on DB to show it in the UI. Maybe we should do that asynchronously?
(In reply to Lucas Rocha (:lucasr) from comment #1)
> The current about:home code doesn't limit the number of thumbnails. So,
> depending on the number of bookmarks you have, the number of updateImage()
> calls might be even higher. In the new design though (see bug 706667) we
> only show up to 4 thumbnails.

4 for phones, but this could increase for tablets.

> Each updateImage() call involves decoding the image stored on DB to show it
> in the UI. Maybe we should do that asynchronously?

Sounds like a good idea to me. Could we use simple placeholders in the thumbnails while we load the real ones?
(In reply to Mark Finkle (:mfinkle) from comment #2)
> (In reply to Lucas Rocha (:lucasr) from comment #1)
> > The current about:home code doesn't limit the number of thumbnails. So,
> > depending on the number of bookmarks you have, the number of updateImage()
> > calls might be even higher. In the new design though (see bug 706667) we
> > only show up to 4 thumbnails.
> 
> 4 for phones, but this could increase for tablets.

Good point.

> > Each updateImage() call involves decoding the image stored on DB to show it
> > in the UI. Maybe we should do that asynchronously?
> 
> Sounds like a good idea to me. Could we use simple placeholders in the
> thumbnails while we load the real ones?

I think we can. We should probably do a similar thing for awesomebar too (for favicons).
Updating the bug title to better match what needs to be done.
Summary: AwesomeCursorViewBinder.updateImage is called way too much in the startup path → Load top site thumbnails asynchronously in native about:home
Priority: -- → P4
Blocks: 721008
Whiteboard: startup → startup, startup-ux
Is this still needed for final release? We could land it after Fx13 if the performance is acceptable.
(In reply to Mark Finkle (:mfinkle) from comment #5)
> Is this still needed for final release? We could land it after Fx13 if the
> performance is acceptable.

My guess is that we'll most likely have good enough performance with the current code as the main bottleneck is the DB query part, not the image loading. Need data that back my assumption though :-)
blocking-fennec1.0: --- → +
Assignee: nobody → lucasr.at.mozilla
blocking-fennec1.0: + → -
Severity: blocker → normal
This has been done as part of bug 785945. Closing.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.