807529 - Gaia homescreen app: do not wait for mozApps to start painting

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

Description

[Philipp von Weitershausen [:philikon]]

One of the biggest problems in Homescreen startup performance is navigator.mozApps.mgmt's performance. This in itself is not an easily fixable problem, though some improvements are underway (bug 805293). Gaia will have to live with the fact that it usually takes a few (!) seconds to load app data via the DOM API. We must therefore change the Homescreen to start painting before this data is available. This essentially means caching all the data that's needed to paint in IndexedDB (which is an order of magnitude faster than mozApps) and then backfilling it with mozapps data later.

Along with this change, we should make the Homescreen key apps not by origin but by manifestURL since that's the unique identifier for them.

NB: This is a somewhat large change to the Homescreen codebase since it changes a bunch of assumptions that's made by the current implementation.

Comment 1

[[:fabrice] Fabrice Desré]

If that helps, I think we should rather return iterators and not arrays from functions like mozApps.mgmt.getAll()

Comment 2

[Philipp von Weitershausen [:philikon]]

(In reply to Fabrice Desré [:fabrice] from comment #1)
> If that helps, I think we should rather return iterators and not arrays from
> functions like mozApps.mgmt.getAll()

This would help with other things, but not necessarily this particular problem.

Comment 3

[Philipp von Weitershausen [:philikon]]

Attachment: pull request

This rewrites the bowels of the Homescreen app (persistency, state management, drawing, etc.) to draw as fast as possible. This means caching everything we need to draw the grid in IndexedDB, including the translated app name and icon (as blob, already rendered with drop shadow), and NOT waiting for slow APIs like mozApps. The storage model is simpler with bookmarks and mozApp icons in the same database, and the dock simply being the 1st grid page in the database. We also now use manifestURL (plus entry_point where applicable) as the key for apps instead of origin and handle entry_points correctly in all places now.

With all of these changes, we start painting icons about 1.5 seconds sooner than before. Painting all icons takes less than 1.5 seconds now instead of 4-5 seconds before. Memory usage (USS and as reported by about:memory) drops by more than 1 meg.

Comment 4

[Philipp von Weitershausen [:philikon]]

Attachment: pull request (correct one)

Was pointing to the wrong pull request.

Comment 5

[Nicholas Nethercote [inactive]]

This may save over 200 KiB of memory consumption in the Homescreen;  see bug 806383 comment 19 (and earlier comments for context).

Comment 6

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 678935 [details]
pull request (correct one)

r- because of the changes in init.json that will break DEBUG=1 and GAIA_DOMAIN. Also I would like to see a fix for the underlying but that crash the homescreen (which reload fast!) before landing that.

Comment 7

[[:fabrice] Fabrice Desré]

(In reply to Vivien Nicolas (:vingtetun) from comment #6)

> Also I would like to see a fix for the underlying but that
> crash the homescreen (which reload fast!) before landing that.

Which crash are you referring to? the one we see only on desktop builds?

Comment 8

[Philipp von Weitershausen [:philikon]]

(In reply to Fabrice Desré [:fabrice] from comment #7)
> (In reply to Vivien Nicolas (:vingtetun) from comment #6)
> 
> > Also I would like to see a fix for the underlying but that
> > crash the homescreen (which reload fast!) before landing that.
> 
> Which crash are you referring to? the one we see only on desktop builds?

Bug 809727.

Comment 9

[Philipp von Weitershausen [:philikon]]

Comment on attachment 678935 [details]
pull request (correct one)

I addressed your comments, Vivien, and a bunch of other bugs. There's still a few follow-up fixes that we should address (to avoid holding on to too much memory, to get updates right, and to improve the UX even further), but they shouldn't block this. I'll be filing them and starting work on them shortly.

Comment 10

[Philipp von Weitershausen [:philikon]]

Attachment: squashed commit v1

Everything squashed into one big commit as requested in the pull request.

Comment 11

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://github.com/mozilla-b2g/gaia/commit/16c28d0acb6fc2d6e3c38da1dc4f9ab97f3bddf7

Comment 12

[Cristian Rodriguez (:crdlc)]

IMHO this new feature had a lot of risk and it had to be reviewed by me as well. For example, currently I've installed the master and I cannot uninstall apps (bookmarks are ok), I cannot add to homescreen apps from ev.me search (from wrappers works fine, ),... The idea is amazing, very hard work and I am very happy with it but we had to review with more detail

Comment 13

[Jose Manuel Cantera]

If this change is introducing so many new bugs I think it would be a good idea to back it out. If navigator.mozApps is slow it should be fixed but no the HS which has reached an stability status that it is worth keeping.

Comment 14

[Cristian Rodriguez (:crdlc)]

I don't know if there are several bugs or not. I only detected 3 bugs. The other bug is about not working the ev.me categories because of descriptor undefined. Although I am totally agree with Cantera