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

Status: RESOLVED WORKSFORME

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

Description

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

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.

Comment 1

[Andrew Overholt [:overholt]]

https://bugzilla.mozilla.org/show_bug.cgi?id=862870#c2

Comment 2

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

https://bugzilla.mozilla.org/show_bug.cgi?id=862870#c3

Comment 3

[Alex Keybl [:akeybl]]

Same as https://bugzilla.mozilla.org/show_bug.cgi?id=862870#c4. Thanks Andrew.

Comment 4

[James Lal [:lightsofapollo]]

Not actively looking at this since its no longer tef?

Comment 5

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

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.

Comment 6

[Mason Chang [Inactive] [:mchang]]

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.

Comment 7

[Mason Chang [Inactive] [:mchang]]

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.

Comment 8

[Mason Chang [Inactive] [:mchang]]

Attachment: init.png

Reflow during the 'init' phase of email.

Comment 9

[Mason Chang [Inactive] [:mchang]]

Attachment: folderSwitch.png

Screenshot of reflows switching from inbox to bugmail folder. My inbox has 234 messages, my bugmail folder has 368 messages.

Comment 10

[James Lal [:lightsofapollo]]

Mason- There is a way to share a public link to the profile results can you use this in addition to the screenshot?

Comment 11

[Mason Chang [Inactive] [:mchang]]

Hi James! Sure thing, the profile results are in comment #7.

Comment 12

[Dylan Oliver [:doliver]]

Tagging this bug to put it in the productivity backlog

Comment 13

[Mason Chang [Inactive] [:mchang]]

Attachment: Github Pull Request - Wrong

I still need to check how much we save on reflow.

Comment 14

[Mason Chang [Inactive] [:mchang]]

Comment on attachment 8345045 [details] [review]
Github Pull Request - Wrong

Woops, attached the pull request to the wrong bug.

Comment 15

[Mason Chang [Inactive] [:mchang]]

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

Comment 16

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

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