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

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

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

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.

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.

(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

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.

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

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

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.