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)
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.
Assignee | ||
Comment 1•13 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?
Comment 2•13 years ago
|
||
(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•13 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•13 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
Updated•13 years ago
|
Priority: -- → P4
Assignee | ||
Updated•12 years ago
|
Whiteboard: startup → startup, startup-ux
Comment 5•12 years ago
|
||
Is this still needed for final release? We could land it after Fx13 if the performance is acceptable.
Keywords: fennecnative-releaseblocker
Assignee | ||
Comment 6•12 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 :-)
Updated•12 years ago
|
blocking-fennec1.0: --- → +
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → lucasr.at.mozilla
Updated•12 years ago
|
blocking-fennec1.0: + → -
Updated•12 years ago
|
Severity: blocker → normal
Assignee | ||
Comment 7•12 years ago
|
||
This has been done as part of bug 785945. Closing.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•