Closed Bug 862872 Opened 11 years ago Closed 10 years ago

[email] UI: improve sync performance and UI responsiveness by not touching scrollTop or otherwise causing reflows


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

Gonk (Firefox OS)


(tracking-b2g:backlog, b2g1828+)

2.0 S4 (20june)
tracking-b2g backlog
Tracking Status
b2g18 28+ ---


(Reporter: asuth, Unassigned)



(Keywords: perf, Whiteboard: [c=handeye p= s=2014.06.20.t u=])


(2 files, 1 obsolete file)

From the perf workshop, we know that we need to eliminate/minimize our scrollTop reads/writes.  Currently, we are spending so much time in these that the app is unresponsive for ~1 second during initial sync.

jlal has a plan for this and thinks he can get to it on Friday.

Bug 862870 is a complementary bug to improve our batching.
Flags: needinfo?(bugmail)
Same as Thanks Andrew.
blocking-b2g: tef? → -
tracking-b2g18: --- → +
Not actively looking at this since its no longer tef?
Assignee: jlal → nobody
I believe there were 2 levels of plan discussed here:

- Non-fancy: Optimize the existing implementation: Cache all layout sizing values that might be causing reflows.  Only insert/remove nodes when the user is not actively scrolling when possible.

- Fancy: Implement a virtual coordinate space.  Messages currently have a fixed-height display and with a little work the message database is capable of providing both the total number of messages in a folder as well as an explicit position index in the folder for any given message.  Use this to explicitly size the scroll content area and do the virtual-table thing where we absolutely position messages into the scroll area on visibility demand.  So the user can scroll wildly around, but we avoid fetching/filling the messages until we reach an idle point, at least on our single core devices that simply can't do two things at once.
Keywords: perf
OS: Linux → Gonk (Firefox OS)
Priority: -- → P2
Hardware: x86_64 → ARM
Whiteboard: [c= ]
Assignee: nobody → mchang
Looks like a 560ms reflow according to this profile:

This is on my personal Mozilla email account, switching view from my inbox to my bugmail folder, which contains 300 messages.
Whiteboard: [c= ] → [c= p= s= u=]
Whiteboard: [c= p= s= u=] → [c= p=4 s= u=]
Per data requested, here is a profile during the init phase of Email. I started the profiler after I entered my account credentials, but before clicking "go to mail".

Here is another profile where I open up my bugmail folder, which was never opened before.

The init phase looks like it has one long 500 ms reflow, whereas the bugmail switching has a bunch of smaller reflows. One thing we might be able to do is instead of reflowing after a certain number of messages, might be better to reflow once every second or something instead. 

I have also attached two screenshots showing the reflow. I'm not sure if the reflow is actually taking that long, or the profiler is interpreting it as a reflow.
Attached image init.png
Reflow during the 'init' phase of email.
Attached image folderSwitch.png
Screenshot of reflows switching from inbox to bugmail folder. My inbox has 234 messages, my bugmail folder has 368 messages.
Mason- There is a way to share a public link to the profile results can you use this in addition to the screenshot?
Flags: needinfo?(mchang)
Hi James! Sure thing, the profile results are in comment #7.
Flags: needinfo?(mchang)
Target Milestone: --- → 1.2 C6(Dec6)
Tagging this bug to put it in the productivity backlog
Target Milestone: 1.2 C6(Dec6) → ---
Attached file Github Pull Request - Wrong (obsolete) —
I still need to check how much we save on reflow.
Attachment #8345045 - Flags: review?(bugmail)
Attachment #8345045 - Flags: review?(bugmail)
Comment on attachment 8345045 [details] [review]
Github Pull Request - Wrong

Woops, attached the pull request to the wrong bug.
Attachment #8345045 - Attachment description: Github Pull Request → Github Pull Request - Wrong
Attachment #8345045 - Attachment is obsolete: true
blocking-b2g: - → backlog
Unassigned since I won't be able to get it to anytime in the foreseeable future.
Assignee: mchang → nobody
Priority: P2 → P3
Whiteboard: [c= p=4 s= u=] → [c=handeye p= s= u=]
I think we basically fixed this with bug 796474.  Any reflow/glitchiness is now a result of other problems...
Closed: 10 years ago
Resolution: --- → WORKSFORME
Whiteboard: [c=handeye p= s= u=] → [c=handeye p= s=2014.06.20.t u=]
Target Milestone: --- → 2.0 S4 (20june)
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.