915121 - [1.2] Regression in Email Message List Scroll FPS (compared to [1.1]

Status: RESOLVED FIXED

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

Description

[Mandyam Vikram]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36

Steps to reproduce:

Based on high speed camera measurements (on a QRD 7x27 device), there seems to be a degradation in UX scroll performance of the Email App.



Actual results:

Measurements on 1.2:
34 FPS 
Measurements on 1.1:
55 FPS

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

How quickly/often can we get the measurements repeated on the nightlies?

Comment 3

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

There's really 2 different FPS's possible for the e-mail app:

A) Nothing is being done in the background, so all the device is doing is scroll-painting.

B) E-mail is doing stuff in the background.  This could be synchronizing the folder, downloading snippets, etc.

Do we know if this number is from our 'A' performance or our 'B' performance?

The way to get 'A' performance is to wait for the sync to finish, as indicated by the refresh button ceasing to do its rotation animation, then scroll around enough to make sure the snippets have already been fetched.

In one of the other FPS bugs it was proposed that we try and make the 'B' performance better by realizing when the user wants to scroll and backing off on the amount of work we're doing in the background.  Which is something we can generally do, although there are obviously trade-offs there.  If the user is nervously scrolling, they will inhibit snippet fetching, which might make them sad/hate the e-mail app, etc.

The other complication is when we scroll and fetch more data from the back-end and insert extra stuff into the DOM.  That is more likely to look like 2 long pauses/hitches in scrolling.  If the magic video tool can show us milliseconds-per-frame, that should be somewhat obvious.

(And of course if we get the async tile-based rendering turned on for our message list, everything becomes fine for free.)

Comment 4

[Mandyam Vikram]

Seems to me that we would need to account for (B) since that use case is almost guaranteed and would cause more CPU workload which could worsen scroll performance. Also, tile-based rendering is turned off for v1.2.

Comment 5

[Kevin Grandon :kgrandon]

Latest test as of 10/01 is showing 57 frames per second which is a huge improvement of 34 frames per second. While the graphics team is still working on improving scroll performance, I'm going to close this out as fixed for now. Please reopen if you are still seeing this.

Comment 6

[Peter Bylenga [:PBylenga]]

(In reply to Kevin Grandon :kgrandon from comment #5)
> Latest test as of 10/01 is showing 57 frames per second which is a huge
> improvement of 34 frames per second. While the graphics team is still
> working on improving scroll performance, I'm going to close this out as
> fixed for now. Please reopen if you are still seeing this.

Re-opening per instructions in Comment 5.  Attaching logcat with FPS enabled of scrolling through messages in Email App.  Also attaching logcat of launching Email app (with account previously setup) until all ui is loaded.

In both cases the average FPS is ~33 FPS.


Environmental Variables
Device: Buri v1.2 COM RIL
Build ID: 20131107004003
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/26f1e160e696
Gaia: 590eb598aacf1e2136b2b6aca5c3124557a365ca
Platform Version: 26.0
RIL Version: 01.01.00.019.281 
Firmware Version: US_20131104

Comment 7

[Peter Bylenga [:PBylenga]]

Attachment: EmailFPS_Scrolling_log.txt

Comment 8

[Peter Bylenga [:PBylenga]]

Attachment: EmailFPS_Launch_log.txt

Comment 9

[Mandyam Vikram]

We are observing something similar as well. Please treat the following results as not final (testing in progress).
We are observing FPS numbers of ~37 fps for the following build:
Gecko:
964f7c844f2793092bab72612d5da2f5bcfd6c2e
Gaia:
be4ea00a50236b10eb0a03232a28ffd0048e0cb8

Also, we are seeing similar regressions in FPS for Contacts (44 fps) and SMS (47 fps).

Please treat this as a showstopper issue as formal CS is next week.

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Mandyam Vikram from comment #9)
> We are observing something similar as well. Please treat the following
> results as not final (testing in progress).
> We are observing FPS numbers of ~37 fps for the following build:
> Gecko:
> 964f7c844f2793092bab72612d5da2f5bcfd6c2e
> Gaia:
> be4ea00a50236b10eb0a03232a28ffd0048e0cb8
> 
> Also, we are seeing similar regressions in FPS for Contacts (44 fps) and SMS
> (47 fps).
> 
> Please treat this as a showstopper issue as formal CS is next week.

I'm going to make a new bug for this since the dependencies are likely going to be different, etc.  It will be easier to track as a new bug.

Comment 11

[Ben Kelly [:bkelly, not reviewing]]

Marking this resolved again.  Please discuss the new regression over on bug 936535.

Comment 12

[Mandyam Vikram]

On profiling this build during Contacts Scroll, these are my observations:
- frames are taking about 22-24 ms to render which translate to 40/42 fps
- Compositor rendering (CompositorOGL->BeginFrame/CompositorOGL->EndFrame) or (LayerManagerComposite::Render) is taking about 11-12 ms

So, it appears that the FPS is not compositor bound.