1551982 - Parallel Styling in the parent-process can lead to drop frames/stutters in children processes on core constrained device

Status: RESOLVED WORKSFORME

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

Description

[Mayank Bansal]

https://perfht.ml/2VDpo4v

Notice that there are clear 2 areas in the profile with dropped samples. These correspond to styling in the parent process.
Could it be that parallel styling leads to using too much CPU, leading to CPU starvation on WR threads?

I have been noticing this phenomenon for some time. Typically, gaps in the profile correspond to styling.
This is probably more noticable with WR enabled, than with WR disabled.

I am on a 2C/4T mobile Broadwell processor. Win10x64, Intel HD 5500 , 8GB RAM
(I know stylo uses max of (6,.75*num_of_cores), so at least 1 thread is left free)
Maybe we should prioritize WR threads over stylo?

Feel free to WONTFIX or INVALID this bug

Comment 1

[Mayank Bansal]

and by gaps, I mean the gaps in the profile around the 9s mark, in the WRWorkers threads, WRbackend etc.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Hmm, so that's styling 2k elements in the parent process, coming from a ThemeChanged callback. Do you know how that happened? Were you changing your system settings when this happened?

Comment 3

[Mayank Bansal]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Hmm, so that's styling 2k elements in the parent process, coming from a
ThemeChanged callback. Do you know how that happened? Were you changing your
system settings when this happened?

I was not manually changing the Windows themes.
But I do have the setting to periodically change the Windows colour theme change based on the colour of the wallpaper.
So every 1 minute, the windows them color will change, and so will the tab-bar color of Nightly.

I had reported a bug earlier, and you had asked this very same question at: https://bugzilla.mozilla.org/show_bug.cgi?id=1533815#c5 :)

Happy to run any diagnostic builds etc to help with this issue, btw.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Ah, true that. I think that we assume ThemeChanged() is relatively rare, and thus we don't particularly optimize it and just restyle the world.

We could optimize this by keeping track of the elements that have theme-dependent colors and restyling only those. But looks to me that in the parent process most elements would be affected by that so we would need to do it even in a more targeted way (knowing which colors changed). The first step would be for the Windows widget code to know that, it's not clear to me if it does or it just has a generic ThemeChanged notification.

If we knew that we could potentially keep track of the specified color on the style system and optimize away restyles of elements that don't use them. Though that would require a bunch of memory, so not 100% sure we can do that.

Comment 5

[Mayank Bansal]

This is pretty east to repro. Just right click on a win10 desktop, and click on "Next desktop background". As the background changes, the theme-color also changes, leading to restyling.

https://perfht.ml/2WXWkoa

Here, I am playing a youtube vid, and while it is playing, I changed the desktop background multiple times.

Comment 6

[Mayank Bansal]

Emilio, do you think it would be useful to reduce the priority of Stylo threads to "low" or "below normal" ?

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Hmm, probably not, styling is pretty common compared to a bunch of other tasks. I suspect instead the media tests should be prioritized higher if anything.