860606 - [Gallery] When selecting picutre in gallery app, it takes too long to be displayed

Status: RESOLVED WORKSFORME

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

Description

[Leo]

1. Title : When selecting picutre in gallery app, it takes too long to be displayed
2. Precondition :
 1) Restore 100 images ( 2560x2058 resolution)
3. Tester's Action : Run gallery app >> Select image
4. Detailed Symptom : Gallery app takes 2.0 seconds(3 times average), however it should be under 1.0 seconds according to leo device spec
5. Expected : Gallery app takes under 1.0 second
6. Reproducibility: Y
1) Frequency Rate : 100%
7. Gaia revision :

Comment 1

[Leo]

I change Precondition

1) Restore 100 images (2560x2058 resolution)
--> Restore 100 images in external sdcard (2560x2058 resoultion)

Comment 2

[Alex Keybl [:akeybl]]

leo+ for now assuming this is a regression, and qawanted to find out if v1.0.1 is affected. If yes, please mark as blocking-b2g:tef?

Comment 3

[Darren]

Pictures 2560x2058 do not display since they are too large for the phone to view.(Limited to 5 megapixel(2560x1920) and lower)
Checked with 100 2560x1920 photos, while the phone was loading the photos and selecting a photo it took a little bit to load the picture. Once all 100 had been loaded, the pictures loaded up relatively fast.

Checked on Unagi build:
Build ID: 20130415070202
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/2b44e2c40cc1
Gaia: c79e761bae4d92f329154c64159f4f5c8eb49c9e

Comment 4

[Leo]

Our chipset vendor's Hardware decoder has only one instance , so till all the images are loaded , Fullscreen image view takes time.

Comment 5

[Leo]

Also, it would be better not to display images  till scanning of all files are done.
maybe a notification of scanning would be good.

Comment 6

[Ting-Yuan Huang]

I did some simple profiling,

thumbnailClickHandler: 36.59 // thumbnailClickHandler() called.
showFile: 36.601 // showFile() called.
D/memalloc( 1444): /dev/pmem: Unmapping buffer base:0x46c31000 size:5242880 offset:4628480
D/memalloc( 1444): /dev/pmem: Unmapping buffer base:0x46900000 size:2457600 offset:1843200
D/memalloc( 1444): /dev/pmem: Unmapping buffer base:0x474f3000 size:2719744 offset:2637824
D/memalloc( 1444): /dev/pmem: Unmapping buffer base:0x471f6000 size:2539520 offset:2457600
_displayImage: 38.039 // _displayImage set this.image.src
_displayImage: 38.061
_displayImage: 38.081
anonymous: 38.193 // this.image.onload()
anonymous: 38.251
anonymous: 38.255

So the delay seemd to be GC related.

BTW, I also observed an ~1.7sec delay between thumbnailClickHandler and showFile when Gallery is entered first time. This is because that showFile is called in the callback function to LazyLoader.load('frame_scripts.js').

Comment 7

[Ting-Yuan Huang]

This bug should be eased with the solution to bug 854795 since the enormous memory usages, hence GC overheads, mainly come from the huge images.

Comment 8

[David Flanagan [:djf]]

If this bug is saying that the app is slow to display photos while it is also scanning photos, I think that is expected. Scanning photos is very CPU and memory intensive if the photos do not contain good previews.

This is expected.  If you test with photos taken with the camera app, this won't happen.  Only if you test with photos from other devices, and that is an unrealistic test.

It think we should close this INVALID or WONTFIX.

Comment 9

[Leo]

Hi dfj,

While loading the Gallery images,if user selects any image to view,its taking long time compared to normal view.

Just wanted to know your opinion,
why dont we try, 
For Eg: while loading if user selects any image to view we will pause the Gallery loading and after view is completed we will resume loading.

Comment 10

[David Flanagan [:djf]]

I really don't think this is an issue we need to worry about.  The scanning process is only CPU and memory intensive when you put large photos with small previews on the phone.

Most users are not going to do this. Those that do will do it rarely.  In normal use, the user will take 10 or 20 photos with the camera, and then visit the gallery app.  Those photos from the camera will scan quickly and there really won't be a problem. (Unless you've modified the camera app so that it does not embed big enough EXIF previews.)

Bug 861965 landed on master today. When it, and the gecko patch it depends on get uplifted, you'll see a big difference in scan time for those large 5 megapixel images.  Instead of taking ~5 seconds per image, they now take ~1.8 seconds per image.  Hopefully that will help.

I feel that there are too many other high-priority items to worry about a corner case like this.

Comment 11

[David Flanagan [:djf]]

(In reply to Leo from comment #9)

> Just wanted to know your opinion,
> why dont we try, 
> For Eg: while loading if user selects any image to view we will pause the
> Gallery loading and after view is completed we will resume loading.

It would be difficult to pause scanning because scanning is build into the mediadb library deeply.

But even if we did pause scanning, the scanner could only pause after it completed whatever image it was currently processing. So there would still be a delay in showing the desired image to the user.

Comment 12

[Dylan Oliver [:doliver]]

Leo, can you retest and give your opinion now that bug 861965 is fixed?

Comment 13

[Leo]

Hi doliver, 

100 jpeg images with 2592x1944 resolution takes approximately 3mins 51 secs to complete loading .
During Gallery scanning process, opening a single image(jpeg, 2560x2048 resolution) takes 1.5 to 1.8 sec approximately.
After Gallery scanning process ,opening a single image(jpeg, 2560x2048 resolution) takes 0.5 sec approximately.

Tested on GAIA Version : 0f7cae830cd9cc143c4f9e6eefb637bafe38b882

Comment 14

[Leo]

Hi ,

Can you please uplift the patch to V1-train.

Comment 15

[Dylan Oliver [:doliver]]

Discussed with Leo and determined that the current performance is acceptable for 1.1. Resolving worksforme since there are no new patches in this bug specifically.