Kan-Ru Chen [:kanru] (UTC+9) Reporter
	Description • 9 years ago

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.

	Wei-Cheng Pan [:wcpan] [:wcp] [:legnaleurc] (left Mozilla) 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

	Wei-Cheng Pan [:wcpan] [:wcp] [:legnaleurc] (left Mozilla) 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

	Wei-Cheng Pan [:wcpan] [:wcp] [:legnaleurc] (left Mozilla) 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

	BMO Automation
	Comment 4 • 7 years ago

Firefox OS is not being worked on