1743870 - High CPU usage on oxide.computer

Status: NEW

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

Description

[Dennis Schubert [:denschub]]

Attachment: Raw data from about:support

On my 2018 MacBook Pro, Firefox constantly consumed ~300% CPU with the site just sitting there.

STR:

1. Open https://oxide.computer/
2. Scroll down all the way to the bottom to load all contents.
3. Wait.

about:processes says most CPU work happens in MediaPDecoder and MediaSupervisor threads.

I have recorded two profiles:

• One with the "Graphics" preset: https://share.firefox.dev/3xGQ18p
• A second one with the "Media" preset: https://share.firefox.dev/3lsu0VP

I've also attached the raw data from about:support to this bug.

Comment 1

[Jim Mathies [:jimm]]

Related, I hit this OOM here on Windows -

https://crash-stats.mozilla.org/report/index/1d5bd483-8511-46bf-8307-a17010211201#tab-annotations

Comment 2

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #1)

Related, I hit this OOM here on Windows -

https://crash-stats.mozilla.org/report/index/1d5bd483-8511-46bf-8307-a17010211201#tab-annotations

I think this might be related to my having the media panel extension enabled while testing.

Comment 3

[C.M.Chang[:chunmin]]

The CPU usage is ~250% on my Linux and MBP. I only see one MediaElement on the page but lots of animations drawn in the <span> blocks. Each CPU peak have nsRefreshDriver::Tick and nsRefreshDriver::RunFrameRequestCallbacks calls, but not sure if it's related. Set to S4 for now. Feel free to change it.

Comment 4

[:glob ✱]

Not sure who "feel free to change it" is directed at, but this appears to be more than "(Small/Trivial) minor significance, cosmetic issues, low or no impact to users". Extremely high CPU has a large impact on power usage and responsiveness, pushing me to use a non-Firefox browser to view that page 🙁

Comment 5

[Alastor Wu [:alwu]]

I can confirm that this issue is media related. From the profiled result, on MediaDecoderStateMachine thread I see a lot of MDSM::Seek calls happening and then the result would be discarded by MDSM::DropVideoUpToSeekTarget. These two things happen again and again, which made the CPU busy.

The temporary workaround for this is, change the blocking autoplay policy for this site to Block audio and video. By doing so, when visiting oxide.computer, the website would not start playing those videos (they would show like images). That can lower the CPU usage to under 10%.

Comment 6

[Alastor Wu [:alwu]]

After some investigation, I think this is a website issue. Here is what happened.

First, this site serves differents DOM content between Firefox and Chrome, that is why this site won't cause high CPU usage on Chrome. On Firefox, there are three video elements, the first one is a super tiny video, which source is transparency-test.webm. This is 1*1 video and its duration is 0.04s. This video exists on both Firefox and Chrome, and the site would keep playing this video. (but this is not the cause of high CPU usage)

Other two video elements only exist on Firefox (On Chrome, the site serves still images, not video) are sled-nvme-annimation.mp4 and sled-connector-animation.mp4. These two videos are also short, their duration are relatively 2s and 3.53s. When a user starts scrolling down the page, the sled-nvme-annimation.mp4 will start playing, and quickly reaches to the end in 2s.

OK, then the bad thing happens. When the video reaches to the end (2s), it would dispatch ended event. Then the site (oxide) will set v.currentTime=2 on that video, which would cause us to seek to 2s. After seeking to 2s, it would trigger (from the step11) another ended event based on the spec (see 3-3).

dispatch ended -> oxide set video current time to 2 -> start another seeking -> dispatch ended -> ......

Therefore, there will be a loop, a pretty quick loop! By looking the profiled result in comment0, seeked event was dispatched 35 times within 0.1s!! That made the main thread super busy. As the video is short, the seeking would be finished within a very short period of time, and then those events would trigger another seeking done by oxsite.

Same thing would happen on another video sled-connector-animation.mp4. These two videos would keep dispatching events to main thread and causes very high CPU usage. The solution would be to ask the oxide not to set v.currentTime = duration when they receive ended event, because it doesn't help anything.

Comment 7

[Alastor Wu [:alwu]]

I've reported this issue to them, so let's wait to see if we could hear any news from them.