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.

Not actively looking at this since its no longer tef?

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.

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] Github Pull Request - Wrong Woops, attached the pull request to the wrong bug.

Unassigned since I won't be able to get it to anytime in the foreseeable future.

I think we basically fixed this with bug 796474. Any reflow/glitchiness is now a result of other problems...