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

Is this a regression from v1.2?

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

Uplifting bug 943498 should help here.

Mason's bug will also affect.

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

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

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.

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

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.

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

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

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...)

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.

Sample video demonstrating blanking

(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.

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.

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

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.

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

The FPS is pretty close to 60 FPS with APZC.

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!

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.

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.

QA, Please test per comment 24.

(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.

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.

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?

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?

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?

I should have some results early next week.

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.

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

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.