1117523 - [Gallery][dolphin][FFOS7715 v2.1] [performance] Open a background Gallery app spend a longer time

Status: RESOLVED WONTFIX

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

Description

[[e-mail]]

*** Build Information ***
Gaia-Rev        73be51f998031f06db0cd660c0e388fa621c9f4c
Gecko-Rev       30de9395e2c3e4c3d640bc6c70ddbc1a8c8cf88f
Device-Name     dolphin

*** Description ***
Gallery app first start-up spend a longer time.

*** Steps to Reproduce ***
1.Fill the device with 250 contacts, 50 call logs, 100 sms, 300 images, 150 music, 50 video.
2.Open Gallery and press home button to switch Video app in background.
3.Open Gallery which is hide in background.

*** Expected Results ***
The background Gallery app is opened promptly.

*** Actual Results ***
The performance of Gallery open in Firefox OS is worse than flame & Android.

*** The average time ***
7715ea-FFOS ：1.26s
Flame-FFOS  ：0.956s
7715ea-Android: 1.083s

Comment 1

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

To me I think the time difference between Dolphin 2.1 and Flame are ignorable.. However, I do notice one thing when we try to bring the Gallery app from background to foreground: Some grids will take longer to show. I capture a video for that:

https://www.youtube.com/watch?v=ANHzf7RLYrM&list=UUApn8BPUaSx9AqEJ6_tYplg

This happens on both Flame 2.1 and Dolphin 2.1. David, do you have any ideas about this one?

Thanks

Vance

Comment 2

[David Flanagan [:djf]]

This is probably a result of bug 1039943. On devices with 256mb of memory or less, when the gallery app is scanning photos and is sent to the background, it exits to avoid scanning photos in the background. Bug 1039943 was filed because the background scanning was slowing down other apps. 

So what is happening in this bug is that you think you are just bringing the gallery app to the foreground, but you are actually doing a cold launch of the app. So it takes longer.

See the doNotScanInBackgroundHack() function at the end of gallery.js  I think that if you remove the call to that function, it will make that bug go away. But it will bring back bug 1039943.

A proper fix would have the gallery app stop scanning without actually killing it. But that is a non-trivial bug that I would not want to attempt to fix and uplift to 2.1.

Comment 3

[jinchao.wang]

(In reply to David Flanagan [:djf] from comment #2)
> This is probably a result of bug 1039943. On devices with 256mb of memory or
> less, when the gallery app is scanning photos and is sent to the background,
> it exits to avoid scanning photos in the background. Bug 1039943 was filed
> because the background scanning was slowing down other apps. 
> 
> So what is happening in this bug is that you think you are just bringing the
> gallery app to the foreground, but you are actually doing a cold launch of
> the app. So it takes longer.
> 
> See the doNotScanInBackgroundHack() function at the end of gallery.js  I
> think that if you remove the call to that function, it will make that bug go
> away. But it will bring back bug 1039943.
> 
> A proper fix would have the gallery app stop scanning without actually
> killing it. But that is a non-trivial bug that I would not want to attempt
> to fix and uplift to 2.1.

Dear David:
    Thanks for your feed back.

    In our test steps, we send gallery to background after gallery complete scanning and parsing. The function of doNotScanInBackgroundHack() can only be effective when gallery is scanning.

    Beside,in our side code, we use a patch replaced doNotScanInBackgroundHack(). The function cause Gallery exit occasionally when opening gallery，because setTimeout({window.close()}) of previous quit didn't invoked until this time‘s opening happened. And another problem is when gallery is scanning and lock screen,gallery will exit.

    In a word，I didn't think it's doNotScanInBackgroundHack() cause "Open a background Gallery app spend a longer time".

Comment 4

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Per further discussion with partner, they agree that the current performance is good enough. So close this one as won't fix