1504490 - Opening a tab in background can jank the current tab while scrolling

Status: RESOLVED WORKSFORME

(Core :: Graphics: WebRender, defect, P5)

Description

[Mayank Bansal]

Attachment: aboutsupport.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

1.Use my normal profile with ABP
2.Open  https://www.androidpolice.com/2018/11/03/oneplus-6t-review-flagship-no-asterisk-necessary/   in a background tab
3. Scroll the current tab


Actual results:

With WR, scrolling the current tab is janky
non-WR is much smoother


Expected results:

WR should be smooth as well. 

non-WR : https://perfht.ml/2JCEyxk
WR: https://perfht.ml/2JFM4b6


Profile looks like time spent in stylo and JS. Maybe with WR enabled, the background tab uses multiple threads for styling ?  just a guess.

Comment 1

[Mayank Bansal]

I have a 2C/4T mobile corei3 processor. 
This janky scrolling is my number one gripe with WR, and which makes it unsuitable for daily use.

Comment 2

[Mayank Bansal]

WR+sequentil Stylo : https://perfht.ml/2JAgZFv

not much of a difference, so i guess stylo is not to blame.

Comment 3

[Mayank Bansal]

non-WR+sequential stylo : https://perfht.ml/2JBYmkG

Comment 4

[Matt Woodrow (:mattwoodrow)]

Jeff, nical, have you seen anything like this?

It looks like the Renderer thread just stalls for extended periods, mainly waiting on the kernel (including NtQueryLicenseValue). It looks like we're really struggling to get profiler samples in the same period.

This is a 2C/4T i3 machine, is it possible that we just have too many threads trying to do work and we end up starving the Renderer?

Comment 5

[Nicolas Silva [:nical]]

> This is a 2C/4T i3 machine, is it possible that we just have too many threads trying to do work and we end up starving the Renderer?

Maybe? Somewhat odd if this is reliably reproducible.

We could start playing with thread priorities if only to validate the cause, I'm somewhat uneasy about it because in my experience once you start bumping a thread's priority you an quickly end up needing to bump another one (because of thread dependencies) and so on and so forth, although the renderer seems to not have too many complicated dependencies with other threads so it might be fine. We'd probably end up starving the render backend thread instead though if it that's what the problem is. Long/medium term I'd like WR to have less threads (merge the render backend and renderer or merge the render backend and compositor or even all three) because scheduling hazards are such a pain to identify/debug.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Couple of options for next steps here:
1) make a try build with thread priorities adjusted and see if it helps
2) get a Gecko profile including all Firefox threads and an OS profile at the same time to try and figure out what is actually happening during the time period in question. The CPU cores might be busy with some other process or with non-gfx threads and this might help identify what's going on.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

Bumping to P4 because it doesn't widespread.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

P5 is the new P4