993886 - [Gallery]it needs a long time to scanning pictures that number is more than 2000

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Gallery, defect, P1)

Description

[sync-1]

Firefox OS v1.3
 Mozilla build ID:20140323004002
 
 DEFECT DESCRIPTION:
 It needs a long time to scanning pictures that number is more than 2000
 
  REPRODUCING PROCEDURES:
 1.There are more than 2000 pictures in sd card;
 2.Launch gallery;
 3.It start scanning pictures.It needs more than 15 minutes to finish scanning.->KO
 
 Note:Beetle Lite FF would force close when there are many pictures in sd card.
 
  EXPECTED BEHAVIOUR:
 Should speed up the scanning speed to improve user experience.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:5/5

Comment 1

[:gerard-majax]

This is something that is still present. With the new dogfooding program and the Z3/Z3 Compact support, people may start producing lots of photo. As a dogfooding user that used to have a good camera on my device (Nexus S), I have a lot of pictures on my sdcard.

I suspect here the culprit is not the Gallery app itself but the API it uses. Still, scanning for media is hugely slow compared to the same hardware running Android:
 - initial scan is very long, as documented in comment 0
 - update scan whe you load the gallery app is also very long

This makes the user experience quite bad:
 - on an Android device, you take a picture, you open the gallery app, it's already here
 - on a B2G device, you take a picture, you open the gallery app, it will take 5-10 secs to start scanning for new pictures, and then again several seconds to find new ones.

Comment 2

[Doug Sherk (:drs) (inactive)]

This is something that we can deal with after we ship, so I'm not going to nom this for now. Having said that, I'm putting it on our list of top issues that aren't blockers.

Comment 3

[David Flanagan [:djf]]

I believe that Dave is working on a change to the DeviceStorage implementation where gekco will continuously keep track of all media files on the device in the background. So when gallery starts up, gecko will very quickly be able to pass a list of files (or a list of new files). That will basically make the "update scan" go away.

The initial scan and thumbnail creation is also an issue, and is currently slower on master than it was in 2.1. I suspect that it will speed up when gecko imagelib stabilizes and gaia is modified to no longer use #-moz-samplesize, but I'm not certain about that.  Because of gecko changes, the Gallery app is actually currently pretty unstable in a lot of ways.

I have a patch that I thought was needed for 2.2 that should fix this. (If turned out not to be needed, but I do need to remember to land it on master). It modifies gallery so that it processes new images from newest to oldest. This will help the initial scan seem faster because the thumbnails that will be displayed at the top of the app will appear first.  (I forget the bug number. It may have been closed. I need to find that patch!)

Longer term, I'm considering a refactoring where when an image is found, we immediately show a default thumbnail of some sort and then switch to the real thumbnail when we've had time to scan it.

Comment 4

[David Flanagan [:djf]]

The bug I was referring to above is bug 1164164. I'll work to get that landed today. That won't improve the overall speed, but will make the gallery app much more usable during its initial scan.

Comment 5

[BMO Automation]

Firefox OS is not being worked on