1370575 - Overpainting when composing a reply in GMail

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

This might be a dupe of an existing bug, but I didn't see an obvious candidate when I searched.

I noticed very sluggish performance while typing a reply to a message in a GMail thread today. When I turned paint flashing on, it appears that every character I typed was forcing the entire message viewing pane to repaint (rather than just the message composition box or some smaller area).

A similar effect is also visible when composing a new message, though the sluggishness isn't as apparent since it's only the repainting the new message pane when typing.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Attachment: screen recording

I recorded this on a clean profile.

Comment 2

[Jet Villegas (inactive)]

Smells a bit like bug 1343538. I'll find us someone to dive deeper here.

Comment 3

[Jet Villegas (inactive)]

Markus: I'm assigning this one to you since you're already looking at bug 1343538. If we find that root causes are different, let's fix GMail first. Thx!

Comment 4

[Jean Gong :jgong]

Markus confirmed that he will try to get this bug fixed by Fx57.

Comment 5

[Jean Gong :jgong]

This might not make it for 57 so I am moving it to P2 for post 57 work.

Comment 6

[Daniel Holbert [:dholbert]]

I can still reproduce, though -- this isn't bad in a *new* compose message.

It's only super-bad (invalidating approximately the whole viewport) in replies to an existing email thread, as shown in RyanVM's screencast.

Bumping to P1 since this is a common workflow and GMail is a commonly-used site. :) Markus, do you think you can still get to this? If not, maybe mattwoodrow can take a look?

Comment 7

[Matt Woodrow (:mattwoodrow)]

I can reproduce this too, stealing.

This is the same underlying issue as bug 1442844, where we reflow a frame multiple times (the first with a 0 size), and generate unnecessary invalidations from the first one.

DLBI normally handles this well, but the table code still does manual invalidation, and results in this.

I think we can fix this particular case, but the general problem is harder to fix.

Comment 8

[Matt Woodrow (:mattwoodrow)]

Attachment: Do less manual invalidation when tables changes, and rely on DLBI instead.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a5bfd78a9594
Do less manual invalidation when tables changes, and rely on DLBI instead. r=mstange

Comment 10

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/a5bfd78a9594