Closed Bug 822965 Opened 12 years ago Closed 8 years ago

app startup animation costs 100-200ms in firstPaint

Categories

(Firefox OS Graveyard :: Gaia, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: zbraniecki, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

Tested with changes from bug 780692 the startup animation still costs between 100 and 200ms depending on the load. I don't know which CSS does Homescreen boot transition but I expect it to be affected as well. firstPaint, avg of 5 cold boots: || 63fa5a2 || noanim || % ===========||=========||=========||========= Settings || 1508 || 1398 || -7.3% Dialer || 1745 || 1550 || -11.1% SMS || 1647 || 1523 || -7.5% Email || 5048 || 4963 || -1.7% Calendar || 2231 || 2044 || -8.4% Contacts || 1865 || 1697 || -9.0%
Attached patch patch (obsolete) — Splinter Review
patch of the code I use to disable animation
We should investigate optimizing it in the future, but the animation is a UX-P1 issue so we've decided this overhead is acceptable.
Attached patch updated patchSplinter Review
updated patch that I use
Attachment #693766 - Attachment is obsolete: true
With the better test framework from bug 825137, I retested the impact of noanim patch on the current gaia: || master || noanim || % ===========||=============||=============||========= Template || 1027 (30) || 821 (25) || -206 Settings || 2685 (265) || 2283 (140) || -401 SMS || 1877 (27) || 1628 (17) || -248 Calendar* || 2626 (103) || 2578 (641) || -47 Email || 5511 (290) || 5369 (134) || -141 Contacts || 3247 (144) || 2924 (46) || -323 *) In case of Calendar app I observed many more outliers with slower startup time (in the 3800ms zone) with the patch than without, but too little sample to draw any conclusions. Based on the trends that I observed, there are apps that get a very clear win when animation is removed - Template app, SMS app, Settings app and Contacts app all received a clear and easy to reproduce boost and a drop in variance on top of that. The Calendar app did not follow this pattern. The variance actually increased with the animations off, and there were multiple very-slow cases. No idea why. I'd like to retest it with patch from bug 812396 landing. Overall, it seems that I'm seeing a greater impact than expected 100ms
In case of Template app: 150ms of that slows down mozbrowserloadstart on the child process (so slows down before the document loading happens), 50ms slows down document loading.
A lot of how app windows are created has changed over the last year. Probably worth looking to see if this is still valid.
Closing this old B2G bug.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: