Closed Bug 862872 Opened 10 years ago Closed 9 years ago
[email] UI: improve sync performance and UI responsiveness by not touching scroll
Top or otherwise causing reflows
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.
Same as https://bugzilla.mozilla.org/show_bug.cgi?id=862870#c4. Thanks Andrew.
blocking-b2g: tef? → -
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.
Status: ASSIGNED → NEW
OS: Linux → Gonk (Firefox OS)
Priority: -- → P2
Hardware: x86_64 → ARM
Whiteboard: [c= ]
Assignee: nobody → mchang
Status: NEW → ASSIGNED
Looks like a 560ms reflow according to this profile: https://people.mozilla.org/~bgirard/cleopatra/#report=0c224778de1a83369d36d024967499061ac0b9e6&search=reflow This is on my personal Mozilla email account, switching view from my inbox to my bugmail folder, which contains 300 messages.
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". https://people.mozilla.org/~bgirard/cleopatra/#report=be449aa69edab986acd7f3622a2dcbbf93148ede&search=reflow Here is another profile where I open up my bugmail folder, which was never opened before. https://people.mozilla.org/~bgirard/cleopatra/#report=4c840f4d71e69b61a5fd022d7ea1dc12a46d845a 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.
Reflow during the 'init' phase of email.
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?
Hi James! Sure thing, the profile results are in comment #7.
Tagging this bug to put it in the productivity backlog
I still need to check how much we save on reflow.
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
Unassigned since I won't be able to get it to anytime in the foreseeable future.
Assignee: mchang → nobody
Status: ASSIGNED → NEW
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...
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Whiteboard: [c=handeye p= s= u=] → [c=handeye p= s=2014.06.20.t u=]
You need to log in before you can comment on or make changes to this bug.