Closed
Bug 1188228
Opened 9 years ago
Closed 7 years ago
[Aries] The App close time is too long when closing the App
Categories
(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect, P2)
Tracking
(tracking-b2g:+)
RESOLVED
WONTFIX
tracking-b2g | + |
People
(Reporter: kanru, Assigned: wcpan)
References
Details
(Keywords: perf, Whiteboard: [perf-wanted])
There was bug 913769 which is similar.
Definition of app close time: the duration between user hit the home button and the end of app close transition.
I think the app close transition itself is fine. The problem is before we start the app close transition we seem to freeze for about several hundreds of milliseconds. Comparing to the original Android on the same device which could start the app close transition instantly, our user experience is inferior.
Sorry I don't have numbers at hand but I think it's worth measuring.
Reporter | ||
Updated•9 years ago
|
Summary: The App close time is too long when closing the App → [Aries] The App close time is too long when closing the App
Assignee | ||
Comment 1•9 years ago
|
||
Profiling result (removed screenshot hack):
- home screen touched : 20ms
- change button color : 10ms
- childVisiblity change + painting : 20ms
- change button color = white : 10ms
- wait : 20ms
- handle homescreen callback : 5ms
- switch app : 20ms
- restyle something : 90ms
# anime start
- wait home screen : 100ms
# anime ended
- atc_do_opening : 75ms
- atc_do_closing : 30ms
- onMutations : 10ms
- paint something: 10ms
Updated•9 years ago
|
Whiteboard: [perf-wanted]
Assignee | ||
Comment 2•9 years ago
|
||
Precondition: open 20 apps in background
Patched: don't take screenshot on switch app
https://people.mozilla.org/~bgirard/cleopatra/#report=6b1c4f72f27fb408854fe514d847ee80d762d268&search=restyle&selection=0,1,63,64,65,260
119ms: ElementRestyler::ComputeStyleChangesFor : windows
Patched: don't take screenshot on switch app, set inactive apps display: none
https://people.mozilla.org/~bgirard/cleopatra/#report=d2ac4805229b2426737560469a320d7d6d5e7fd9&search=restyle&selection=0,1,10,11,12,294
18ms: ElementRestyler::ComputeStyleChangesFor : windows
Updated•9 years ago
|
Assignee: nobody → wpan
tracking-b2g:
--- → +
Assignee | ||
Comment 3•9 years ago
|
||
More detailed summary:
# don't take screenshot on switch app
https://people.mozilla.org/~bgirard/cleopatra/#report=6b1c4f72f27fb408854fe514d847ee80d762d268&search=restyle&selection=0,1,63,64,65,260
awm_switchApp -> 27ms
RestyleTracker::ProcessRestyles -> 149ms
ElementRestyler::ComputeStyleChangeFor (windows) -> 118ms
PresShell::Paint -> 64ms
atc_handle_opened -> 19ms
RestyleTracker::ProcessRestyles -> 145ms
ElementRestyler::ComputeStyleChangeFor (windows) -> 122ms
sb_resumeUpdate + Statusbar._updateMinimizedStatusbarWidth -> 27ms
translateFragment -> 12ms
(waiting for displaylist) -> 320ms
ContainerState::ProcessDisplayItems -> 22ms
# don't take screenshot on switch app, set inactive apps display: none
https://people.mozilla.org/~bgirard/cleopatra/#report=d2ac4805229b2426737560469a320d7d6d5e7fd9&search=restyle&selection=0,1,10,11,12,294
awm_switchApp -> 21ms
RestyleTracker::ProcessRestyles -> 56ms
ElementRestyler::ComputeStyleChangeFor (windows) -> 25ms
PresShell::Paint -> 28ms
atc_handle_opened -> 10ms
RestyleTracker::ProcessRestyles -> 47ms
ElementRestyler::ComputeStyleChangeFor (windows) -> 22ms
sb_resumeUpdate + Statusbar._updateMinimizedStatusbarWidth -> 8ms
translateFragment -> 14ms
(waiting for displaylist) -> 300ms
ContainerState::ProcessDisplayItems -> 6ms
BTW, opening a manifest-only view then switching back to home screen is very fast, because it only need to restyle items in the home screen, not the whole windows.
Setting display: none to invisible AppWindow(s) can reduce the delay time, especially if there are many inactive apps.
Further more, if we have a faster getScreenshot() API then we may have a even lower delay.
But this change will break some animations (task manager screen, edge gesture ... etc.), is it possible to forward this to UI team?
Things to do are:
1. remove getScreenshot() in AppWindow.prototype.tryWaitForFullRepaint
2. display: none on inactive apps if possible
Updated•9 years ago
|
Priority: -- → P2
Comment 4•7 years ago
|
||
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•