Load top site thumbnails asynchronously in native about:home

RESOLVED DUPLICATE of bug 785945

Status

()

Firefox for Android
General
P4
normal
RESOLVED DUPLICATE of bug 785945
7 years ago
5 years ago

People

(Reporter: dougt, Assigned: lucasr)

Tracking

unspecified
All
Android
Points:
---

Firefox Tracking Flags

(blocking-fennec1.0 -)

Details

(Whiteboard: startup, startup-ux)

(Reporter)

Description

7 years ago
I see AwesomeCursorViewBinder.updateImage called seven times on the main thread before Gecko is loaded.  This accounts for about 3% of startup.
(Assignee)

Comment 1

7 years ago
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?
(Assignee)

Comment 3

7 years ago
(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).
(Assignee)

Comment 4

7 years ago
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
(Assignee)

Updated

6 years ago
Blocks: 721008
(Assignee)

Updated

6 years ago
Whiteboard: startup → startup, startup-ux
Is this still needed for final release? We could land it after Fx13 if the performance is acceptable.
Keywords: fennecnative-releaseblocker
(Assignee)

Comment 6

6 years ago
(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)

Updated

6 years ago
Assignee: nobody → lucasr.at.mozilla
blocking-fennec1.0: + → -
Severity: blocker → normal
(Assignee)

Comment 7

5 years ago
This has been done as part of bug 785945. Closing.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 785945
You need to log in before you can comment on or make changes to this bug.