[music][ui] Views take a long time to display with large music collections

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
4 years ago
7 months ago

People

(Reporter: hub, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
I have over 2000 tunes in the Music app. If I list all songs, or even all albums (much smaller list) or artists, and start scrolling down until you only have black, it takes a few second for the list to update and display.

(this is a Flame)
(Reporter)

Updated

4 years ago
Blocks: 1121186
I can reproduce this issue on OGA & NGA music app of FlameKK v2.5 latest build by STR in comment 0.
Device: Flame KK v2.5(Affected)
Build ID               20150921073455
Gaia Revision          2d370fa35c1a0ee2a637e3772c0843586a5f96c9
Gaia Date              2015-09-21 02:41:31
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/039a8490891595736b16a3ccb17f025f4dcf13eb
Gecko Version          44.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150921.112037
Firmware Date          Mon Sep 21 11:20:52 EDT 2015
Bootloader             L1TC000118D0
Blocks: 1205048
QA Whiteboard: [MGSEI-Triage+]

Comment 2

3 years ago
Hub is going to test this case out on the NGA app. Ni'ing him.
Flags: needinfo?(hub)
(Reporter)

Comment 3

3 years ago
I has different performance characteristics. For example if I tap on the "songs" tab, it take a few seconds to display more than an empty list. 

I have gaia 9a682cb7 on this Sony Z3C. From the OTA
BuildID is 20151002103912
Flags: needinfo?(hub)

Comment 4

3 years ago
It might be worth checking to see how long the database query takes. If it's taking way too long, we'll (eventually) have to fix this by switching away from enumerateAll().
(In reply to Jim Porter (:squib) from comment #4)
> It might be worth checking to see how long the database query takes. If it's
> taking way too long, we'll (eventually) have to fix this by switching away
> from enumerateAll().

Yes. This is probably an issue with either the time it takes to run the query or the time it takes to pass the results across the bridge. We should check both. If it is the query, we can probably break it up into two calls: one to get a summary listing of about 10-20 songs, the other to get the remainder.

Longer term solution is to move away from MediaDB and take our architecture (and its limitations) into consideration when designing the replacement DB.
(Reporter)

Comment 6

3 years ago
For the record, the performance is different, and scrolling down to the list is definitely faster than it used to be.
Github issue tracking new caching feature: https://github.com/gaia-components/gaia-fast-list/issues/4

Updated

3 years ago
Summary: Scrolling is slow with a lot of songs → [music][ui] Views take a long time to display with large music collections

Updated

3 years ago
Duplicate of this bug: 1117047
This should be improved since bug 1214771 landed. The first view of a panel will take the same time, but once the list cache is primed, subsequent view should be very fast.

One other way we can improve this is 'prerendering' the Artists, Albums and Songs panels on app launch. Although having all these panels rendered, will bump up memory usage.

If QA are happy with the new perf let's close this, if not, let's open and block on a new 'add panel prerendering' bug.
(In reply to Wilson Page [:wilsonpage] from comment #9)
> This should be improved since bug 1214771 landed. The first view of a panel
> will take the same time, but once the list cache is primed, subsequent view
> should be very fast.
> 
> One other way we can improve this is 'prerendering' the Artists, Albums and
> Songs panels on app launch. Although having all these panels rendered, will
> bump up memory usage.
> 
> If QA are happy with the new perf let's close this, if not, let's open and
> block on a new 'add panel prerendering' bug.

Yes, pre-rendering is definitely the way forward with this and this is a technique that was proposed via NGA using markup to specify which views should be pre-rendered in the background. However, it is too late to do it for v2.5 as it may introduce performance regressions (especially memory).

Comment 11

7 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.