1482264 - Lots of paints during tab switch

Status: NEW

(Core :: DOM: Content Processes, defect, P3)

Description

[Jeff Muizelaar [:jrmuizel]]

4 paints per tab switch 3 of new, one of old
https://perfht.ml/2w11al5

Comment 1

[Mike Conley (:mconley) (:⚙️)]

I can reproduce this, with or without WebRender.

STR:

1. Open two tabs, where the 1st tab has some text that you can select.
2. In the first tab, select some text.
3. Start the profiler
4. Switch to the 2nd tab without deselecting the text

ER:

No paint occurs for the tab we're switching away from.

AR:

A paint occurs in the backgrounded tab because we're blurring the selection:

https://searchfox.org/mozilla-central/rev/aff5d4ad5d7fb2919d267cbc23b1d87ae3cf0110/layout/base/nsDocumentViewer.cpp#3835

I think this is happening because we don't drop the layers and deactivate the PresShell of the backgrounded tab right away.

We might want to do something else for backgrounded tabs so we can keep their layers around but make them cheaper to have back there.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

For the paints on the tab we're switching to, the first paint is one with displayport suppression enabled to optimize tab switch time, the second with suppression disabled to avoid checkerboarding. The third is because Google Docs is, I believe, updating itself based on the visibility state firing.

So the one I think we might want to optimize is the background-ing tab with the selection.

Comment 3

[Florian Quèze [:florian]]

In the profile from comment 0, it seems optimizing out the paint of the tab we are switching away from wouldn't have a visible performance impact because the 2 tabs happen to be on different content processes. So this would help more with battery usage than with speed. So I'm tempted to make this p3. But on the other hand, doing useless paints is something we should really avoid, and hopefully add regression tests for, so I'm also tempted to put a higher priority.