426445 - High CPU usage in Flash causes setInterval() timers to starve

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Darrick Brown]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13

When a Flash movie is on the page that uses a large amount of video and CPU power, Firefox starves any timers running.  When under load, Firefox timers (setTimeout(), setInterval()) do not fire.  This problem is reproducible 100% of the time on slower/lower end Windows XP machines.  If the machine is higher end, the bug may only reproduce occasionally or not at all.  So when attempting to reproduce this bug, please use a lower end machine or Windows XP in a VM (WinXP on Parallels on my MacBook Pro reproduces this problem every time).

Reproducible: Always

Steps to Reproduce:
1. On Windows XP, in Firefox 2.0.0.13, open: http://preview.videoegg.com/firefox/loadtest.html
This page contains an 800x600 video on the left and a textarea on the right.  The 800x600 video is intended to use up a good chunk of CPU/video.
2. Do not play the video yet.  The textarea at the right prints the current time every second on a js timer created with setInterval().  Notice the timer is firing correctly.
3. Play the video.  Notice the timer hangs while the video is playing.
4. Pause the video.  Notice the timer resumes its expected behavior.

Bonus:

1. Open multiple tabs in Firefox.
2. Play the video.
3. Notice that you can't click between tabs while the video is playing.
4. Pause the video.  Suddenly, Firefox swaps to the last tab clicked.
Actual Results:  
While video is playing, js timers and switching between browser tabs do not work, or are extremely laggy.  The events are getting starved.  It appears that Firefox may be attempting to improve Flash/plugin performance by servicing it on a higher priority basis.  However, this scheduling is starving other necessary events.

Expected Results:  
All events should be serviced in a reasonable manner without any events being starved.  Under load, I would expect things to run a bit slower, but all events should get through.

This bug happens most readily when Flash has its window mode set to "transparent" or "opaque" ("windowless" mode in the NPAPI), which uses more CPU.

Comment 1

[Darrick Brown]

Firefox 3.0 appears to handle this case fine.  However, that might be due to all the performance enhancements that went into 3.0.  Perhaps the bug is still in there, but the performance improvements in 3.0 allow the events to be serviced ok.  The bug may still be lurking in there.  It's probably worthwhile to investigate the root cause of the issue in 2.0 and make sure that 3.0 isn't simply masking it.

Comment 2

[Darrick Brown]

Setting blocking flags as instructed by Damon Sicore.

Comment 3

[Mike Connor [:mconnor]]

This would be a Core bug, in any case.  We've changed a lot of things beyond perf that should help with this on trunk, like better timers, etc.

Comment 4

[Daniel Veditz [:dveditz]]

Fix would be nice, but not a "blocking" bug.

Comment 5

[Terje Rosenlund]

Attachment: test setInterval()

Test-case shows CPU load under varying conditions when using setInterval()
(instructions on page)

The problem depends on the complexity in the function called by setInterval()

Using a timer to load a small document on regular intervals (2 sec) by XMLHttpRequest are now using about 50% CPU capacity in a very 'un-nice' way

Comment 6

[Terje Rosenlund]

Comment on attachment 318142 [details]
test setInterval()

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

The hight CPU load reported in my test-case was due to exhausted memory caused by a memory leak in mozilla.

Lack of memory caused disk-swap which gives a CPU load of 100%, indicating a very selfish disk-swap routine (?)

Comment 7

[Wayne Mery (:wsmwk)]

high cpu also with v3.1.  But no lockout or UI delay.
Is this still deemed a problem with v3.1. And if it is, isn't this a duplicate?

Comment 8

[Nickolay_Ponomarev]

OK, since the original bug doesn't happen in 3.0, resolving this bug. Darrick, thanks for your report and the updates, but realistically, there's no chance the issue will be separately debugged in 2.0 to check if there may still be an (invisible) issue in 3.0...

Terje: thanks for the testcase. It's not related to this bug at all though. If you can still reproduce with the latest build (I can't; see http://nightly.mozilla.org/ for links to the latests builds), please open a separate bug about it.