I'm filing this bug to have a place to fix a number of long-standing issues with gallery's scanning and startup behavior. 1) It is hard to use the gallery while it is scanning because files are scanned in random order and thumbnails keep jumping around so it is hard to tap on the one you want. This bug has been filed multiple times, most recently in bug 1028751. 2) If photos are deleted while gallery is not running, the thumbnails for those photos still appear in the gallery until the startup scan completes, which can take 10 seconds or more. This was filed as bug 864674 can can be considered a privacy issue. 3) The gallery will continue to scan and create thumbnails while in the background and this can slow down other apps on low-end hardware. This was reported in bug 1039943 and that bug was fixed with a hack that actually forced the app to exit rather than continuing to scan in the background. At a minimum, this bug must replace that hack with something better. Here's how we might address these items: 1) We currently process images in the same order that the device storage enumeration returns them. This is an attempt to pipeline the device storage enumeration process into the metadata parsing and thumbnail generation process. But dhylands says that internally, device storage does a complete enumeration before returning the individual files. If so, it means that we could instead get an array of all new files, sort them by date, and then process them from newest to oldest. Even better, once we know how many new images there will be, we can add that many items to the thumbnail list, even before we have created the thumbnails. This should prevent all the jumping around. 2) To prevent the display of thumbnails for photos that have been deleted, we obviously need to verify that the file still exists before showing the thumbanil. pdahiya has investigated doing this bug bug 864764, but there are some performance problems with querying the existence of each file individually. At the same time, we can't afford to wait for a full enumeration of the entire sdcard before starting to display thumbnails or our startup will be too slow. Perhaps we can enumerate entire directories and cache the results for existence checking. Ideally we could address this issue directly in mediadb itself so that the db enumeration code never returns items that no longer exist. But we also need to do that without compromising the time it takes to get above-the-fold content displayed in the app. (And note that fixing the mediadb enumeration code might not help apps like Music that do queries rather than complete enumerations.) 3) The video app already separates video thumbnail creation from media db enumeration and scanning, and does not create thumbnails while in the background. I think we need to do something similar with the gallery app so that scanning can continue in the background but that the memory-intensive work of creating thumbnails is not done in the background. This integrates nicely with #1 above if we create new items in the thumbnail display even before the thumbnails have been created. Note that the introduction of a new gallery homescreen (bug 1042311) that displays only a few thumbnails will dramatically changes the startup behavior of Gallery and may change the design decisions we make here.

I had really hoped to work on this for the 2.1 release, but family medical leave, 2.0 blockers, and PTO have taken up all of my time and I will not be able to work on this until after the 2.1 feature landing deadline.

I've added bug 1021609 as another one to try to address here. That one is about what happens when the sdcard is removed on a device that also has internal storage. We should force a re-enumeration in that case, and when we do, mediadb should be smart enough to not return files that are located on unmounted volumes. (The only policy question in my mind is whether it should immediately delete its records of those files and force them to be rescanned if the card is inserted again. If we delete the records, then we lose things like play count associated with the files. But if we retain them then we might have the issues of showing deleted files when a new empty sdcard is inserted.)

There have been some bugs filed about performance on multi-core devices. This might be a good bug to also investigate using worker threads for metadata parsing. Maybe we could get some speedups when multiple cores are available.

Dave has told me that even though the DeviceStorage API defines a cursor-based interface for enumerating files, the implementation actually goes and finds all the files at once and then passes them through the cursor one at a time. I did some tests on device storage enumeration time, using a Flame which confirm this: With 500 files, it takes about 650ms to get the first file, and then 2ms for each file after that. With 1000 files, it takes about 800ms to get the first file, then 2ms for each file after that If there is more than one storage area (internal/external) to enumerate, the second one seems to go faster, (perhaps because of JIT compilation). If the API gave us a way to get the entire batch of files all at once that would be a big speedup. For 1000 files it currently takes 2800ms to get the full list. If we could get the list in 800ms instead, that would be a huge speedup. Or, if the implementation could pass files back to JS as soon as it finds them, that would be a huge speedup as well. We need to do a full enumeration of the storage every time our media apps start up so we can keep the db in sync with the files that are actually present in the storage, so it is important for this to be fast. Filed bug 1104337 to ask for these device storage changes.

DeviceStorage is not available in web workers, so I can't experiment with enumerating files from a worker to see if that makes any performance difference.

The IndexedDB API is also not currently available in web workers, so I can't experiment with moving any of those mediadb features to workers. Bug 701634 will add this API to workers and is actively being worked on. I'm not going to mark that as a blocker because I don't actually know that workers would help us here any.

When I put 500 pictures on my internal and external storage areas, and then enumerate the two storage areas sequentially, it takes about 2900ms. If I enumerate them in parallel, it is about 2200ms total. That is on a flame. I'd like to try this on a quad core device to see if that makes a difference. But all I've got is a Nexus 4 and it only has one storage area to enumerate, so I can't test that.

Use feature-b2g:3.0? rather than 2.3?.