A youtube live chat with rapid chats uses a lot of CPU. Makes nightly sluggish
Categories
(Core :: Graphics: WebRender, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox67 | --- | affected |
People
(Reporter: mayankleoboy1, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
-
Using my local profile. WR enabled
-
Go to a live youtube chat : https://www.youtube.com/watch?v=LwXeoC6k0Lk
This has a rapid chat window. -
Watch the high CPU usage.
Profile: https://perfht.ml/2EIS1Sv
Reporter | ||
Comment 1•6 years ago
|
||
Reporter | ||
Comment 2•6 years ago
|
||
OK. It is not the video playing that causes janks. I paused the video, and the chats still appear. Then I took a profile.
Reporter | ||
Comment 3•6 years ago
|
||
And another : https://perfht.ml/2EIS68K
It looks like we are continuously buidling display lists, but they dont cause janks. The janks come when we have selctor matching, followed by reflow.
ni? some people.
Reporter | ||
Comment 4•6 years ago
|
||
oops, shouldnt ni so much.
Comment 5•6 years ago
|
||
ni?ing is fine with me, fwiw :)
So, is the jank you're talking about the "347ms event processing delay"?
It looks like that's caused by some media queries changing, from nsPresContext::RefreshSystemMetrics, which is generally system dependent stuff (like default colors or such changing or what not).
That causes us to restyle the whole page, which is what takes long. Other than that, I don't see style so high in the profile, mostly some slow attribute selector matching (uBlock, maybe?).
If that 300ms+ pauses happen often, we should look into what causes it though, ThemeChanged is only supposed to affect rare stuff, like hight-contrast or other default system settings changing.
Reporter | ||
Comment 6•6 years ago
|
||
So, is the jank you're talking about the "347ms event processing delay"?
My observstion on the jank was after I had looked at the profile. The actual subjective feeling when watching the live chat was of general sluggishness, and high CPU use (fan running)
It looks like that's caused by some media queries changing, from
nsPresContext::RefreshSystemMetrics, which is generally system dependent
stuff (like default colors or such changing or what not).
I do have set my Win10 machine to periodically change the system colors, which will also change the browsers tabbar color.
That causes us to restyle the whole page, which is what takes long. Other
than that, I don't see style so high in the profile, mostly some slow
attribute selector matching (uBlock, maybe?).
I do have ublcock installed.
Comment 7•6 years ago
|
||
Hello Mike, could you please look into the profile here? Thanks!
Comment 8•6 years ago
|
||
What I see in the profile is a lot of displaylist creation in the content process... we're (still) getting Polyfilled by Polymer, and periodically the JS causes a sync layout flush:
Hey stpeter, do we know yet how close YouTube is to getting off of the v0 WebComponents spec, and getting us off of the Polymer polyfill on YouTube?
Comment 9•6 years ago
|
||
Looks like at least some of the displaylist creation time is because RDL isn't working overly well. I've filed bug 1535507 for that.
Updated•6 years ago
|
Comment 10•6 years ago
|
||
Hey mconley, we reached out to our YT friends and the answer is "pretty darn close" but we don't have specific dates.
Updated•6 years ago
|
Comment 11•6 years ago
|
||
Mayank, can you confirm this is worse with WebRender?
Reporter | ||
Comment 12•6 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #11)
Mayank, can you confirm this is worse with WebRender?
Its difficult to test with WR disabled, as I run into bug 1509656
But subjectively, WR-off and WR-on didnt feel any different.
Profile with WR off: http://bit.ly/2JQJToN
Reporter | ||
Comment 13•6 years ago
|
||
https://www.youtube.com/watch?v=UVxU2HzPGug .
Start the video a bit, and then pause it. Let the chat mode be "Top chat". The chats eill continue to fly while the video is stopped.
WR off : http://bit.ly/2K0oOrM
WR on: http://bit.ly/2JPEj5Z
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 14•5 years ago
|
||
It looks like this is mostly a problem in the WebContent process with both display list building and webrender display list building taking a pretty big chunk of time.
Updated•5 years ago
|
Comment 15•5 years ago
|
||
Aside from calls to nsIFrame::RemoveDisplayItem(), this seems quite normal display list building profile. There is bug 1526970 filed for improving nsIFrame - display item management.
I think that the root problem here is that new chat messages invalidate the scrollbar, which disables RDL, and forces us to rebuild the whole display list.
Updated•5 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Comment 16•2 years ago
|
||
Is this still relevant (and if so, should it be in the WR component)?
Reporter | ||
Comment 17•2 years ago
|
||
The original links dont work anymore. Might as well close this.
Description
•