1209476 - [Music][NGA] Thumbnails are too large

Status: RESOLVED FIXED

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

Description

[Wilson Page [:wilsonpage]]

Currently thumbnails can be as large as 600x600. This is far too large for Gecko to render and maintain <gaia-fast-list> scrolling performance.

We should have two version of the default album artwork 'large' and 'thumbnail' and only load the large when needed.

Comment 1

[Jim Porter (:squib)]

Are you sure? I wrote the thumbnail generator, and it caps the size at 300x300px.

Comment 2

[Justin D'Arcangelo [:justindarc]]

(In reply to Jim Porter (:squib) from comment #1)
> Are you sure? I wrote the thumbnail generator, and it caps the size at
> 300x300px.

Yes, we are resizing thumbnails to 300x300px. However, default album art never gets resized and we do not generate thumbnails for them. We probably need to pre-shrink default album art into 300x300px thumbnails and have them available for when the app requests a thumbnail version of a song with default album art.

Comment 3

[Jim Porter (:squib)]

Ah, ok. Since this is in the metadata parser (sort of), I'll take this.

Comment 4

[Wilson Page [:wilsonpage]]

Scroll performance dramatically improved after changing the default album artwork to 60x60 thumbnail.

Comment 5

[Jim Porter (:squib)]

I wonder how much scrolling will improve once we make all the duplicate images use the same blob URLs.

Comment 6

[Wilson Page [:wilsonpage]]

(In reply to Jim Porter (:squib) from comment #5)
> I wonder how much scrolling will improve once we make all the duplicate
> images use the same blob URLs.

I don't think it will impact much. 90% of our time is spent in gfx related stuff.

Comment 7

[Justin D'Arcangelo [:justindarc]]

(In reply to Wilson Page [:wilsonpage] from comment #6)
> (In reply to Jim Porter (:squib) from comment #5)
> > I wonder how much scrolling will improve once we make all the duplicate
> > images use the same blob URLs.
> 
> I don't think it will impact much. 90% of our time is spent in gfx related
> stuff.

Right, but it should help our memory consumption once squib fixes the backend to use the same blob URL for duplicate images which is another area we need to optimize as well as speed.

Comment 8

[GitHub Autolander Bot]

Attachment: [gaia] jimporter:music-jpg-placeholders > mozilla-b2g:master

Comment 9

[Jim Porter (:squib)]

Landed: https://github.com/mozilla-b2g/gaia/commit/c3a5bf3af7e61045e1b8757db992ec734a9f3f36

Comment 10

[Wilson Page [:wilsonpage]]

These thumbnails are still too large (300x300). We need to be aiming for about 100x100 (ideally smaller) to give us decent scrolling performance on low-end hardware.

Squib, thoughts?

Comment 11

[Justin D'Arcangelo [:justindarc]]

(In reply to Wilson Page [:wilsonpage] from comment #10)
> These thumbnails are still too large (300x300). We need to be aiming for
> about 100x100 (ideally smaller) to give us decent scrolling performance on
> low-end hardware.
> 
> Squib, thoughts?

This was mainly to improve performance on the tiles view, I believe. I have already talked to :squib about introducing a 3rd size for smaller thumbnails for the list views.

Comment 12

[Wilson Page [:wilsonpage]]

Reopening this to track getting thumbnails small enough to get good scrolling performance on list views.

Comment 13

[Justin D'Arcangelo [:justindarc]]

(In reply to Wilson Page [:wilsonpage] from comment #12)
> Reopening this to track getting thumbnails small enough to get good
> scrolling performance on list views.

I'm closing this to instead track the API modifications in Bug 1213853. The purpose of this bug was to simply address the issues with the default album art not having any thumbnails at all. Now that this is fixed, we will require some API changes to support a second thumbnail size specifically for list views.