483841 - 100% cpu usage on page with video before playing video

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Christopher Blizzard (:blizzard)]

Visit the URL above the the CPU usage of the browser jumps to 100% before you play the video.  Doesn't come down for a while, either, so it's more than just the frame decode cache.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Looks like it happens only during the download - need to clear cache to be able to reproduce. Probably don't want to suck down all the CPU power during that download.

Comment 2

[Christopher Blizzard (:blizzard)]

I've been able to reproduce it without clearing the cache and it doesn't happen 100% of the time, but clearing the cache definitely reproduced it for me.

Comment 3

[Matthew Gregan [:kinetik]]

I don't know if the entire problem can be attributed to this, but a lot of the
CPU use is due to the download progress bar causing a huge number
of invalidations, which are quite expensive due to bug 474748.

It's easy to test how much of the CPU use is due to invalidation and
repainting--while reproducing this bug, switch to another tab.  On my MBP, I
see 100% utilization while loading the test URL in the current tab, and around
15-20% utilization with a different tab in front.  15-20% still seems high
considering all that's going on is the download, so we should probably
investigate where we're spending that time.

We should also look at why the download progress bar causes so much
invalidation (I've seen > 100 repaints per second while downloading).

Comment 4

[Justin Dolske [:Dolske]]

(In reply to comment #3)

> We should also look at why the download progress bar causes so much
> invalidation (I've seen > 100 repaints per second while downloading).

:-o

FWIW, the controls only update the bar's value when a progress event is received (which is about 3 per second, iirc).

Comment 5

[Christopher Blizzard (:blizzard)]

Interesting.  So switching tabs does cause the CPU usage to drop.  But a few things to realize here:

1. The video isn't playing while the CPU usage is at 100%.
2. The 100% usage doesn't go down after the video finishes downloading.
3. If I play the video on that tab the CPU usage jumps to about 140%!  Stopping the video from playing and it drops back down to 100%.

Something is going wrong with something here, that's for sure.

Comment 6

[Matthew Gregan [:kinetik]]

Yeah, I just noticed that it's still high after the download completes, so it looks like I was wrong (sorry dolske!).  I'm not seeing huge numbers of repaints during download on OS X, either (I thought I was on Linux, I'll have to recheck).  During the entire download, and even after download, I'm seeing ~30 repaints/second.  The video code only fires invalidates when currentTime is progressing, I think, so the cause of the repaints must be elsewhere.  I'll dig into this some more...

Comment 7

[Ria Klaassen (not reading all bugmail)]

On Windows I see some change caused by some checkin here:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8eba35e62d92&tochange=a979ac23e17e
But it is not very significant (and maybe not the same).

Comment 8

[Matthew Gregan [:kinetik]]

The throbber, even when hidden, is causing the video frame to be invalidated.  Because the throbber is an animated PNG, it's constantly invalidating (at ~25HZ).  If I set  throbberOverlay to display: none in videocontrols.css, the CPU use drops to 15-20% and we only invalidate when the download progress bar updates (~3HZ).

Comment 9

[Matthew Gregan [:kinetik]]

The fact that the embedded video is 800x400 scaled to 400x300 might be causing us to hit the slow EXTEND_PAD path, too.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

Invalidation of hidden images should be a no-op.

This is a conservative approach. Arguably nsFrame::InvalidateWithFlags should check visibility, but that's a lot scarier so if we're going to do it we should do it in a separate trunk-only bug.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 367904 [details] [diff] [review]
fix

r=dbaron.

A more general fix might be good, but it would break assumptions that invalidating a frame ('s overflow rect) takes care of invalidating its descendants.

Comment 12

[Dave Townsend [:mossop]]

Does this also work for the case where an image is hidden by virtue of being in
a hidden container, say a deck where a different pane is selected?

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No, I don't think this handles that case.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/mozilla-central/rev/17709a5a3fb2

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Justin: there's still *some* CPU usage here since you have the animated image running. It would be nice if you could make it display:none while we don't need it, that would avoid any activity.

Comment 16

[Justin Dolske [:Dolske]]

Ok, opened bug 484935 for that (since this bug already has a different fix, and is FIXED).

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/767a903a483f

Comment 18

[Tony Chung [:tchung]]

Using the URL from comment 0, the CPU usage on video loadup maxes near 30% instead of 100%.   Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090507 Minefield/3.6a1pre
and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090507 Shiretoko/3.5b5pre