950733 - [1.3] Email app stutters

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::E-Mail, defect, P1)

Description

[Mandyam Vikram]

On the Email app, we notice stutters while loading messages.  On a multi-core  device with faster CPUs/GPU, the janks should be minimal.

Comment 1

[Dylan Oliver [:doliver]]

Is this a regression from v1.2?

Comment 2

[Mandyam Vikram]

On more capable devices, the scroll fps should be 60 and these janks affect it.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

Uplifting bug 943498 should help here.

Comment 4

[Dietrich Ayala (:dietrich)]

Mason's bug will also affect.

Comment 5

[Preeti Raghunath(:Preeti)]

Mason,

Can you please provide an update here? This blocks QC CS and a fix is expected by 1/15.

Comment 6

[Mason Chang [Inactive] [:mchang]]

Hi Preeti, I'm still waiting on review for bug 862870, which Andrew said should be reviewed shortly.

Comment 7

[Mike Lee [:mlee]]

Mason, will fixing bug 862870 fix this issue and if not, what else is needed and can it be completed (i.e. fixed and uplifted) by 2014.01.15.

Comment 8

[Mason Chang [Inactive] [:mchang]]

We're hoping that both bug 862870 and 943948 will fix this issue.

Comment 9

[Dylan Oliver [:doliver]]

mvikram, have you re-tested this since bug 943498 has landed? We think that fix may get us most of the way to solving this issue.

Comment 10

[Mandyam Vikram]

No, not yet. Also, need to test it with AZPC enabled now.

Comment 11

[Inder]

Adding the ni back till we have test results from Vikram.

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

Note that my review of bug 862870 (with some review changes made) is basically done, but I'm still in the process of getting my ikura/inari working for testing so I can run with the hw composer on.  (I de-bricked it but the binary blobs are out of date, I think I've almost got that licked, but I may be over-optimistic since I don't have a real ZTE open but am planning to try flash its image bits...)

Comment 13

[Mandyam Vikram]

With APZC turned on, the scrolling appears smoother. However, we notice blanking/checkerboarding during the scroll which affects the fps calculations. Please refer https://bugzilla.mozilla.org/show_bug.cgi?id=942750.
I'm attaching a sample high speed video which demonstrates the issue.

Comment 14

[Mandyam Vikram]

Attachment: emailscroll.mp4

Sample video demonstrating blanking

Comment 15

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Mandyam Vikram from comment #14)
> Sample video demonstrating blanking

It looks a lot like the tester manged to fling themselves to the bottom of the pre-buffered messages and the messages that appeared were just added to the DOM from the back-end.  Which is to say, this is more likely to be an infinite-scroll/scroll buffering issue and less an APZ issue.  I am basing this on a few things; given the lack of context I may be wrong about stuff:

- The scroll thumb is in the process of visibly shrinking when we get to the white-space.  And it's shrinking from a large size.  The shrinking tells me we just added more messages into the DOM.  The large thumb size prior to the shrinking suggests we were at minimum buffering, or possibly even below when this happened[1].  Why the messages were being added is unclear without additional context.

- The scroll thumb ends up at the bottom of the list, then as the video ends, more stuff is showing up.  This absolutely means we hit the bottom of the list in the process, but it does leave some ambiguity as to what was up with buffering.

1: It depends on how long the tester waited after switching to the folder / opening the app; hopefully we had already switched from cached HTML in a cookie to real-backend at that point.  A description of the testing procedure and/or video coverage from the start of opening the app (at a more reasonable speed) would be quite useful.


While I suspect we need to make some changes to our infinite-scrolling logic for other reasons for bug 959782, if the problem is having blank areas of the screen when scrolling, the fix will need to be to increase the number of messages we pre-buffer into the DOM.  The exact number probably wants to depend on the maximum scrolling velocity.  The velocity the tester achieved seems ridiculously high; I can't get that to happen on my Nexus 4.

But anyways, to get a better idea of whether that's the problem or not, it could be useful to modify the constants SCROLL_MIN_BUFFER_SCREENS and SCROLL_MAX_RETENTION_SCREENS in message_list.js.  They live here:
https://github.com/mozilla-b2g/gaia/blob/master/apps/email/js/cards/message_list.js#L25

If we crank those up a large amount and the tester waits for the scroll-thumb to stop flashing after opening the folder, we can then get a better indication of whether we are managing to out-run the APZ / how much buffering we need.  (Of course, just looking at APZ logging or the SPS profiler might be more useful, too.)  The tester will need to wait a bit for the HTML cache to be replaced with 'real' data from the back-end if the app has been freshly opened too.  One way to reset the buffering state without worrying about the cache is to change to another folder and then back to the first folder / inbox.

Comment 16

[Andrew Sutherland [:asuth] (he/him)]

So, I think bug 862870 may matter to what I saw in the video specifically, so I've gone and manually uplifted bug 862870 already so that it should be in tomorrow's build or any re-tests for additional data can include it.

Comment 17

[Dylan Oliver [:doliver]]

Vikram, can you run the test again now with bug 862870 in place?

Comment 18

[Mandyam Vikram]

Repeated the same steps on the following build:
Gecko: db7c69557493ce821d614741090a691300f6721c
Gaia: 1f029aa4c924d6c59fd7e8c6d9786a7370755d49

Still see blanking on fast scrolls. Attaching a couple of videos to illustrate.

Comment 19

[Mandyam Vikram]

Attachment: email_scroll_blanking.mp4

Email scrolling tested with fix for https://bugzilla.mozilla.org/show_bug.cgi?id=862870

Comment 20

[Mandyam Vikram]

Attachment: email_scroll_blanking1.mp4

Comment 21

[Mandyam Vikram]

The FPS is pretty close to 60 FPS with APZC.

Comment 22

[Mason Chang [Inactive] [:mchang]]

Vikram, if the FPS is close to 60 FPS, can we close this bug based on comment 2 or do we still need to eliminate more jank? Based on the video, the checkerboarding looks like it is more related to APZ and bug 942750.

Thanks!

Comment 23

[Andrew Sutherland [:asuth] (he/him)]

I agree with Mason; the videos seem to have a sufficient number of DOM message nodes buffered so the issue demonstrated by the videos is likely to be an APZ or paint-duration issue.

Not sure if we should close this yet though; the last FPS problem was a paint-duration issue due to the ellipsis taking a long time to calculate.  The fix for scrolling there was to cache the ellipsis calculations, but if they still need to be freshly made for the APZ high-speed scroll, that could still be something that might need a workaround in the e-mail app or at least an e-mail specific fix from platform.

Comment 24

[Mandyam Vikram]

Please see https://bugzilla.mozilla.org/show_bug.cgi?id=950733#c23. From a pure FPS point of view, we seem to be close to 60 FPS. I think we might want to investigate the cause of the blanking and raise a separate issue if we determine it is related to APZC and if so, track it via a different bug.

Comment 25

[Preeti Raghunath(:Preeti)]

QA,

Please test per comment 24.

Comment 26

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

(In reply to Preeti Raghunath(:Preeti) from comment #25)
> QA,
> 
> Please test per comment 24.

Preeti, can you clarify? It looks like Vikram has already tested this, determined there is blanking, and is now asking for a root cause analysis.

Comment 27

[Mason Chang [Inactive] [:mchang]]

Attachment: Profile Scrolling Email App

Comment 28

[Benoit Girard (:BenWa)]

Mason the main thread cuts out after the scrolling has started. We'll need another profile. It would help if you prefill the capture command in the terminal, perform the scroll and once the panning begins properly to hit capture immediately.

Comment 29

[Mason Chang [Inactive] [:mchang]]

Attachment: Profile w/ Lots of Scrolling

Comment 30

[Mason Chang [Inactive] [:mchang]]

In reply to comment #28, that's usually what I do. I start the profiling, start a scroll, and push capture immediately. You can't scroll while the profiler captures data, which i thought was why the end cuts off?

Comment 31

[Mason Chang [Inactive] [:mchang]]

Landed bug 962699, which helps with the scrolling and seemed to help with the blanking. The blanking seems to be roughly the same as the other apps and being tracked in 942750. As for the scrollbar hitting the bottom and stopping, that is being tracked in bug 959782.

Can you please retest Vikram?

Comment 32

[Faramarz Rashed]

The dependent bug is slated for 1.4 so this can't be a CS blocker for 1.3
Can we adjust the flags please?

Comment 33

[Mandyam Vikram]

I should have some results early next week.

Comment 34

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

Since Vikram has this, I'm removing qawanted. If you need help from the Mozilla QA team, please replace the kw with a quick summary of what's specifically needed.

Comment 35

[Mandyam Vikram]

Attaching a video of scrolling taken on a build made on 1/27.

Comment 36

[Mandyam Vikram]

Attachment: EMAIL_scroll.mp4

Comment 37

[Mandyam Vikram]

Given that the checkerboarding issue is being tracked via https://bugzilla.mozilla.org/show_bug.cgi?id=965019 and https://bugzilla.mozilla.org/show_bug.cgi?id=942750, we can close this out.