1786040 - Lots of jank on godly.website due to large number of video elements

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect)

Description

[Sky Schubert [:skyschub]]

Via a WebCompat report, we've received a complaint about godly.website experiencing performance issues, especially janky scrolling. Šime captures a profile: https://share.firefox.dev/3ChSjik

That site has a lot of video elements that all autoplay, so it's not surprising that this has an impact on performance. However, Chrome and Safari have almost no trouble on the same hardware, so this might be something we can improve on.

Comment 1

[Sky Schubert [:skyschub]]

It's probably worth noting that all those video elements also have timeupdate listeners, which probably doesn't help.

Comment 2

[Bas Schouten (:bas.schouten)]

Moving to the correct component. Jeff might have ideas on this with relation to the ongoing audio/video work.

The Performance Impact Calculator has determined this bug's performance impact to be low. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: macOS
Impact on site: Causes noticeable jank
Websites affected: Rare
[x] Able to reproduce locally

Comment 3

[Šime Vidas]

If your performance tool cannot detect this issue, then it seems that there is also an issue with that tool.

I just tested that website again in Firefox Nightly. After some 20 seconds of scrolling around, the entire browser started freezing. It got worse and worse. In the end, everything froze completely. I tried to close the tab, but it only closed ~15 seconds later.

Is it just me?

Comment 4

[Mayank Bansal]

At steady state (scroll a little bit down and let all network activity stop) :
Media: https://share.firefox.dev/3sLsPEc
Hw-WR: https://share.firefox.dev/3STIZpJ
Sw-WR: https://share.firefox.dev/3TX1qv5
So, this looks like a gfx issue (too much blur?)

We use much less memory compared to Chrome (230MB Vs 700MB), but use much more CPU/GPU

Comment 5

[Jim Mathies [:jimm]]

Bouncing to Graphics, just looks like a generic rendering perf issue on this particular site.

Comment 6

[Markus Stange [:mstange]]

Šime's profile from comment 0 shows quite a different issue than Mayank's profiles from comment 4.

In Šime's profile, you can see parts where the composites on the Renderer thread are spaced out by multiple seconds. The composites themselves are fast, but they're not getting scheduled frequently enough.
And that's because the Compositor thread is overwhelmed with creating and destroying IOSurface textures for video frames. (The Compositor thread is responsible for scheduling the composites.)

Compositor thread flamegraph: https://share.firefox.dev/3Vk80Mi

Comment 7

[Jeff Muizelaar [:jrmuizel]]

It also seems like we have some CPU starvation caused by lots and lots of media threads.

If we are decoding N videos, how many threads should we have?

Comment 8

[Alastor Wu [:alwu]]

Hi, Šime,
I couldn't reproduce this issue on the latest Nightly, would you mind to try the latest Nightly again to see if this issue still exists? Bug 1262276 should be able to help on this issue, thanks!

Comment 9

[Šime Vidas]

I recorded another profile profile: https://share.firefox.dev/3EQThlt

The website https://godly.website/ is still super janky with abysmally low frame rates at times, but at least Firefox itself now remains responsive, so that’s a big improvement.

Comment 10

[Alastor Wu [:alwu]]

Hi, Šime,
Could you help me use media preset to capture profiling? (you can select preset from the profiler dropdown menu)
Also, could you help me confirm if media.seamless-looping-video is true on your Nightly? Also, would you mind to provide your about:support as well?
Thank you.

Comment 11

[Alastor Wu [:alwu]]

When seamless video looping (media.seamless-looping-video) is enabled, whenever those autoplay videos becomes invisible after 10s (which is something adjustable, but 10s is our default), Firefox would stop video decoding for them in order to save resources.

At least on my Nightly 109 (Windows 10 & MacOS 12.2), I can scroll godly very smoothly, even I've scrolled to the bottom (probably 50+ scrolls) However, if that site is still janky for you, maybe we should consider to implement this spec optional behavior (pausing invisible autoplay video), which should further mitigate the CPU pressure.

Comment 12

[Šime Vidas]

No problem.

Performance profile with media preset: https://share.firefox.dev/3EQQb0W

media.seamless-looping-video is set to true, which is the default value for me.

I’ll add the about:support data as an attachment.

Comment 13

[Šime Vidas]

Attachment: My about:support page

Comment 14

[Alastor Wu [:alwu]]

Hi, Šime,
Could you help me do another experiment? I would like to know if setting media.suspend-bkgnd-video.delay-ms to 0 for you would help janky or not.
Also, comparing it with other browsers, how janky it would be when using them to browse godly?
Thank you.

Comment 15

[Šime Vidas]

Hm, it doesn’t really help. When I scroll the page in the beginning, the page still freezes for about half a second before scrolling. It gets better after a while. Scrolling becomes smoother.

However, my laptop fan starts blowing at full speed. I notice this because it makes a lot of noise. Normally, when I watch videos on YouTube or other sites, the fan does not produce any noise. The fan noise only happens on very few sites, such as https://ventusky.com and Google Earth (beta).

Comment 16

[Alastor Wu [:alwu]]

Thanks for testing! After digging this issue more, I found godly actually has been doing some optimization, which would automatically unbind the video from the DOM tree when they are invisible, which would result in pausing them. (So my proposal in comment 11 won't help on this issue because invisible videos are already paused) As you said your laptop fan was blowing a lot, I wonder if the hardware decoding wasn't kick in for your laptop, which made your CPU super busy.

Could you help me do another experiment?

1. On your Nightly, go to about:logging
2. Type MediaFormatReader:5 in the second cell, then click Set Log Module
3. Now you should see Current Log Module: MediaFormatReader:5 above the cell
4. Go to this video
5. use media preset and start profiling again
6. end profiling after capturing around 5s
7. upload the profiled result and make sure all clicked boxes are selected

Thank you so much!

Comment 17

[Šime Vidas]

Here you go. I hope I did everything right.

https://share.firefox.dev/3irKXB8

Comment 18

[Alastor Wu [:alwu]]

Yes that is what I needed, thanks! From your profiled result, I can see that we already used hardware decoding on your laptop, was that still very janky while you were doing profiling? Because the result shows that the CPU usage isn't high at all in godly process (the peak is only around 13%)...

Comment 19

[Šime Vidas]

Not janky. The video played smoothly.

Comment 20

[Alastor Wu [:alwu]]

Ah, sorry, I forgot the profiled result is just for a single video. Would you mind to profile godly as well with the same steps while the janky issue happens again? (but this time using timestamp,MediaFormatReader:5,MediaDecoder:5,PlatformDecoderModule:5 for the step 2)

Thanks.

Comment 21

[Šime Vidas]

I made two recordings.

1. When I navigate to godly and scroll around while the videos are loading: https://share.firefox.dev/3ivyIU8

2. After some time on the website, when the videos have already loaded, and I scroll around: https://share.firefox.dev/3OYD9mo

Comment 22

[Alastor Wu [:alwu]]

Set NI to myself to investigate this again, I've checked the profile results, but wasn't able to figure out what the root cause is.