1590057 - Fullscreen switching is slow with many tabs

Status: NEW

(Core :: Graphics, defect, P3)

Description

[Kusanagi Kouichi]

Attachment: 800 tabs session

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

1. Open 800 tabs (attached session data)
2. Quit
3. Restart
4. Restore session
5. Press F11

Actual results:

Firefox 69 is slower than firefox 68

Expected results:

Firefox 69 is as fast as firefox 68

Comment 1

[Kusanagi Kouichi]

Attachment: firefox 68

Comment 2

[Kusanagi Kouichi]

Attachment: firefox 69

Comment 3

[YF (Yang)]

Would you like to try Firefox Nightly 71? Full screen code is being rewritten (bug 1505916).

Comment 4

[Kusanagi Kouichi]

Nightly 71 is slow too.

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

It is likely too late to do anything about this for 70. But we'll see how Fission work helps for 72 and maybe even 71.

Comment 6

[Kusanagi Kouichi]

mozregression:
10:41.06 INFO: Narrowed inbound regression window from [6c6b0bbf, 8f15ea3b] (3 builds) to [6c6b0bbf, 5a18f5c9] (2 builds) (~1 steps left)
10:41.06 INFO: No more inbound revisions, bisection finished.
10:41.06 INFO: Last good revision: 6c6b0bbf5885493a0b85cedf1985d6eb3bdbfe6f
10:41.06 INFO: First bad revision: 5a18f5c929ab13bde25f7fff8ae72f87e8fa379c
10:41.06 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6c6b0bbf5885493a0b85cedf1985d6eb3bdbfe6f&tochange=5a18f5c929ab13bde25f7fff8ae72f87e8fa379c

Comment 7

[:Gijs (he/him)]

Do you see this on a clean profile? Have you toggled gfx.webrender.split-render-roots to true on the profile where you see this?

Comment 8

[Kusanagi Kouichi]

Attachment: about:support

(In reply to :Gijs (he/him) from comment #7)

Do you see this on a clean profile?
I tested with a new profile.

Have you toggled gfx.webrender.split-render-roots to true on the profile where you see this?
It's set to false. Setting it to true doesn't change anything.
WebRender seems disabled. Please see the attached about:support.

Comment 9

[:Gijs (he/him)]

I'm stumped, tbh. There's nothing in the about:support data that stands out to me (though it may be worth someone more in tune with the finesses of gfx to take a look - nical?), the change in bug 1549976 I don't think should have affected non-webrender, and I can't tell what's going on in the videos - they move a lot from left-to-right? I don't really understand why - does the same issue not happen if you're going from a maximized window to fullscreen?

One more stab in the dark: on the clean profile, if you toggle toolkit.legacyUserProfileCustomizations.stylesheets to true in about:config, close Firefox, and create a chrome folder in your profile with a userChrome.css file containing:

html|*#fullscreen-and-pointerlock-wrapper {
  display: none;
}

and reopen Firefox, does the problem go away? (You probably don't want to keep that long-term because it'll break pointerlock and fullscreen warnings.)

It's also possible gecko profiles for the before/after would help, but tbh from the video it's not clear to me that there's really a significant difference in how quickly anything happens? It looks maybe more stuttery in 69 (though even that's hard to see because of the horizontal back-and-forth), but not slower in a wall-clock-time sense, and it may be hard to make out the difference in a profile.

Comment 10

[Kusanagi Kouichi]

(In reply to :Gijs (he/him) from comment #9)
userChrome.css doesn't help.
Removing #fullscreen-and-pointerlock-wrapper from browser.xhtml makes fullscreen by F11 fast. But fullscreen by video element is still slow.
I'll attach new videos. They'll show the problem clearer.

Comment 11

[Kusanagi Kouichi]

Attachment: firefox 68 with 3000 tabs

Comment 12

[Kusanagi Kouichi]

Attachment: firefox 69 with 3000 tabs

Comment 13

[:Gijs (he/him)]

Can you use the Firefox Profiler add-on to get profiles of the good/bad behaviour in the 3000 tabs case?

Comment 14

[Kusanagi Kouichi]

firefox 68:
https://perfht.ml/36Lf7VO

firefox 69:
https://perfht.ml/2oYwpNV

Comment 15

[Nicolas Silva [:nical]]

From the profiles, looks like stylo is where things are happening, which I don't know much about. Looks like a lock in Servo_CssUrlData_Release is contended, but I don't know with what (the stylo workers are not recorded in the profile).

Moving from WebRender to the Graphics component since the former does not affect the issue, but I doubt the answer will actually be Graphics.

Perhaps the change in the regression range or some other change that happened around the same time nudged some heuristics somewhere which led more items to be considered by the style system when thousands of (hidden) tabs are present?

Comment 16

[Pascal Chevrel:pascalc (PTO until April 26)]

P3, unassigned, so wontfix for 71 given where we are in the schedule.

Comment 17

[Kris Maglione [:kmag]]

The most suspicious thing I see in this profile is that we spend almost 700ms in Servo_CssUrlData_Release waiting on a lock during the two reflows. That said, the rest of the stacks don't make much sense, so it's not clear what's actually triggering the reflows, or even whether the parts of the stacks that seem to make sense are actually trustworthy. I'm not sure whether this is because of improper symbolication or just because of the way the code is optimized.

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking fix-optional to remove this from weekly regression triage.