1213853 - [Music][NGA] Add a second smaller thumbnail size for list views

Status: RESOLVED WONTFIX

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

Description

[Justin D'Arcangelo [:justindarc]]

In order to improve scrolling performance, the current single thumbnail size is too large. We need to extend our API to offer a second, smaller thumbnail size to be used in list views. Ideally, we can determine what this size should be based on the GAIA_DEV_PIXELS_PER_PX build-time flag.

Comment 1

[Jim Porter (:squib)]

Given that we'll be removing the tiles view in 3.0, we could probably wait until then to do this, and at that point, just switch to 100x100px for all the thumbnails. I'm not too worried about scrolling performance for 2.5, since it should already be better than OGA.

Comment 2

[Jim Porter (:squib)]

I'm just going to post my thoughts about where I'd like to go with this long-term, and then we can decide what to do for 2.5:

Currently, we store all the thumbnails in a cache in asyncStorage. However, asyncStorage isn't particularly well-suited to this job, since it's hard to say "get the cached thumbnail, but create it first if we don't have one" in a single transaction. Our asyncStorage is also polluted with our shuffle/repeat settings for some reason. In the long-term, I'd like to completely drop asyncStorage and use a new system for caching thumbnails, as well as using something else for the shuffle/repeat settings (cookies?).

When I make this change, we'll switch to sizing our thumbnails based on the device pixel ratio. I don't want to do it now because we don't have an easy way of invalidating the old thumbnails (which are all 300x300px). We might only need one size of thumbnail (100x100px-ish for the list views), but maybe we'd want a slightly-larger one for the album-detail view?

In the short term, I can add another size of thumbnail to the cache by just giving it a different key, or we could just drop asyncStorage for 2.5. It wouldn't be that hard to swap out.

Comment 3

[Justin D'Arcangelo [:justindarc]]

(In reply to Jim Porter (:squib) from comment #2)
> I'm just going to post my thoughts about where I'd like to go with this
> long-term, and then we can decide what to do for 2.5:
> 
> Currently, we store all the thumbnails in a cache in asyncStorage. However,
> asyncStorage isn't particularly well-suited to this job, since it's hard to
> say "get the cached thumbnail, but create it first if we don't have one" in
> a single transaction. Our asyncStorage is also polluted with our
> shuffle/repeat settings for some reason. In the long-term, I'd like to
> completely drop asyncStorage and use a new system for caching thumbnails, as
> well as using something else for the shuffle/repeat settings (cookies?).
> 
> When I make this change, we'll switch to sizing our thumbnails based on the
> device pixel ratio. I don't want to do it now because we don't have an easy
> way of invalidating the old thumbnails (which are all 300x300px). We might
> only need one size of thumbnail (100x100px-ish for the list views), but
> maybe we'd want a slightly-larger one for the album-detail view?
> 
> In the short term, I can add another size of thumbnail to the cache by just
> giving it a different key, or we could just drop asyncStorage for 2.5. It
> wouldn't be that hard to swap out.

This all sounds good to me. In the short term, I'm not convinced that we need to do anything differently. Our scrolling performance is already better than the old app and all this would do is possibly improve upon it a little more. In addition, since the tiles view is likely to go away on v3.0, we can just switch everything down to a single thumbnail size that is optimized for the list views. I'm not sure we'd even need a slightly-larger one just for the album-detail view since we could use the smaller thumbnail and dynamically switch it out for the full-size one when its loaded. Since there's only a single image on the album-detail view, this should not impact performance if its larger than the screen area.

Comment 4

[BMO Automation]

Firefox OS is not being worked on