Open Bug 1533815 Opened 9 months ago Updated Last month

A youtube live chat with rapid chats uses a lot of CPU. Makes nightly sluggish

Categories

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

enhancement

Tracking

()

Tracking Status
firefox67 --- affected

People

(Reporter: mayankleoboy1, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

  1. Using my local profile. WR enabled

  2. Go to a live youtube chat : https://www.youtube.com/watch?v=LwXeoC6k0Lk
    This has a rapid chat window.

  3. Watch the high CPU usage.

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

Attached file aboutsupport.txt

OK. It is not the video playing that causes janks. I paused the video, and the chats still appear. Then I took a profile.

https://perfht.ml/2EKnHXr

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.

Flags: needinfo?(matt.woodrow)
Flags: needinfo?(emilio)
Flags: needinfo?(dholbert)

oops, shouldnt ni so much.

Flags: needinfo?(matt.woodrow)
Flags: needinfo?(emilio)
Flags: needinfo?(dholbert)

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.

Flags: needinfo?(mayankleoboy1)

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.

Flags: needinfo?(mayankleoboy1)

Hello Mike, could you please look into the profile here? Thanks!

Flags: needinfo?(mconley)

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:

https://perfht.ml/2T3jPGb

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?

Flags: needinfo?(mconley) → needinfo?(stpeter)
Depends on: 1535507

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.

Component: Untriaged → Graphics: WebRender
Product: Firefox → Core
Blocks: wr-68
Priority: -- → P3

Hey mconley, we reached out to our YT friends and the answer is "pretty darn close" but we don't have specific dates.

Flags: needinfo?(stpeter)

Mayank, can you confirm this is worse with WebRender?

Flags: needinfo?(mayankleoboy1)

(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

Flags: needinfo?(mayankleoboy1) → needinfo?(jmuizelaar)

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

Blocks: wr-69
No longer blocks: wr-68
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(jmuizelaar)
Assignee: nobody → jmuizelaar
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(jmuizelaar)

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.

Assignee: jmuizelaar → mikokm
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(mikokm)

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.

Blocks: 1526970
Flags: needinfo?(mikokm)
No longer blocks: wr-69
Depends on: 1567889
Assignee: mikokm → nobody
You need to log in before you can comment on or make changes to this bug.