1378192 - Loading re:Dash dashboards janks other content processes

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect, P3)

Description

[Jared Lockhart [:jlockhart]]

Firefox Version: Nightly 56

Profile: https://perfht.ml/2sDaf4r

e10s: enabled


When I load a re:Dash dashboard such as:

https://sql.telemetry.mozilla.org/public/dashboards/6NTBpuim6s7KvXw5ozKWA7fIlmEQlPprkRJoJUzg?org_slug=default


I find that other content processes become unresponsive.

I captured a profile which seems to show that the compositor is being really taxed, and the main thread is blocked on waiting for identifiers from the compositor which causes the whole browser to jank.


Steps to reproduce:

1) Start Nightly 56 with e10s enabled and dom.ipc.processCount set to some large number
2) Open a tab with a redash dashboard such as the one above
3) Navigate to another tab other than the redash one and find that it is unresponsive (cursor doesn't change when hovered over links, click events do nothing)

Comment 1

[Andrew Overholt [:overholt]]

Maybe Matt has thoughts here (see as it's Graphics:Layers)?

Comment 2

[Matt Woodrow (:mattwoodrow)]

Unfortunately I wasn't able to reproduce this locally :(

It looks like we're hitting the really slow 'background copy' path for component alpha, and compositing is struggling.

We no longer do this on Windows (with AdvancedLayers), so this is likely to be a Mac specific problem.

We actually tried to disable this entirely in bug 1366618, but it got backed out for bug 1378840.

Some things we can do here:

* Figure out why the URL bar on Mac also hits this tough corner case, and fix it (either in layout/Layers, or by making a frontend change).

* Figure out why greyscale AA on Mac looks so much worse than subpixel-AA, the screenshots in bug 1378840 are pretty horrendous and forcing greyscale for the corner case might be a hard sell.

* Re-land bug 1366618!

* It looks like the current impl is quite bad. We create a temporary surface and delete it immediately after, which looks like a blocking call, so we're not getting any advantage of the GPU being asynchronous. We should defer deletions of these until after compositing has finished, so that we're not stalling the pipeline.

I probably won't have time to work on these in the near future though sorry, maybe Milan has ideas?

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

There is a few different things that can help Mac performance (this, bug 1265824, bug 1366618); let's give them the right qf number and come back to them together.

Comment 4

[Gregory Pappas [:gregp]]

Unable to reproduce