1848357 - Simplify tab displaylist unloading event handling in AsyncTabSwitcher

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, task)

Description

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

From a conversation in Matrix with emilio:

so part of the issue (IMO) is that setting .renderLayers looks very trivial but is quite stateful. And it's also intertwined with .hasLayers and what not... And there are subtle expectations where setting .renderLayers the front-end expects an eventual layerTreeCleared event etc. In this case, the parent layer tree state was getting out of sync with the compositor.

Maybe a simpler setup could be something like "the compositor just notifies when it starts or stops painting a tab" (regardless of the last .renderLayers assignment / epoch / etc).

That has some implications for the front-end where it would need to deal with MozLayerTreeCleared / MozLayerTreeReady event pairs potentially, even though .renderLayers is true. But the end state should be consistent (and maybe you can just ignore events that don't match the state you expect).

Think of a window being minimized or we being on memory pressure. Right now that gives you a spurious MozLayerTreeCleared event which feels like it could cause spinners. My patch would fix that though

Comment 1

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

To be clear, this bug is not about tab content unloading. This is about the AsyncTabSwitcher's notion of unloading display lists.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1848357 - Cleanup layer observer handling. r=mconley!,#gfx-reviewers!

This seems to work, and turns out I need to fix this before bug 1847584,
because the epoch handling breaks with those patches in the case
customize mode sets display: none on browser elements.

Instead of dealing with epochs, just always report the last "has layers"
state to BrowserParent. This is both simpler and more reliable (there
were a couple hacks in WebRenderBridgeParent to make sure we notified
even though a transaction failed).

AsyncTabSwitcher deals with this correctly because it already needs to
deal with browsers that already have layers.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fccf186ac4e8
Cleanup layer observer handling. r=mconley,gfx-reviewers,bradwerth

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1848357 - Remove PaintWhileInterruptingJSNoOp(). r=mconley

This should not be needed anymore. We no longer need to "ack" an epoch,
since there's no epoch.

Make the logic to trigger a paint and request composite a bit more
generic. That doesn't change behavior right now, because our visibility
state is tied to mRenderLayers, but without this change setting
renderLayers = true on a display: none iframe will trigger a useless
paint after bug 1847584.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9d73d3b7b627
Remove PaintWhileInterruptingJSNoOp(). r=mconley

Comment 6

[Atila Butkovits]

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

Comment 7

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/9d73d3b7b627