Closed Bug 558339 Opened 13 years ago Closed 10 years ago
Some flash videos causes CPU usage to spike; browser barely responds to commands
Some flash videos causes CPU usage to spike; browser barely responds to command STR: 1) http://abc.go.com/watch/lost/93372/257416/happily-ever-after CPU spikes for ever and the page doesn't load for a long time (like two minutes). If and once it does, firefox doesn't respond to commands like back, clicking on other tabs, using the menu, context menus. I also have this problem on another site. Usually the only way I can close the tab is to ctrl+tab and then firefox responds to my commands so I can close the now inactive tab with flash in it. I can also reproduce this on another site.
Summary: Some flash videos causes CPU usage to spike; browser barely responds to command → Some flash videos causes CPU usage to spike; browser barely responds to commands
Do you have ABP installed still? I can't reproduce at all, I'm wondering if this is fallout from the plugin-stream landing which just got backed out. Can you reproduce with the 1.9.2 nightlies?
(In reply to comment #1) > Do you have ABP installed still? I can't reproduce at all, I'm wondering if > this is fallout from the plugin-stream landing which just got backed out. Can > you reproduce with the 1.9.2 nightlies? Yes, ABP is installed but not enabled. I can not reproduce with the 1.9.2 nightlies. This bug has been happening for over a week so it isn't related to the plugin-stream landing, I just hadn't filed this sooner because I was trying to find a site that I could publish here.
And this also happen with the flash release prior to the 10.1 RC. I just updated to that two days ago.
I'd love to have a regression range for which nightly this broke on.
I'm beginning to think this is an issue with the flash plugin itself. I've gone back to February and can still reproduce in every weeks build after Feb. 1st. I did not have this problem back then. I tried to find older releases for flash 10.1 to no avail. I know I did not have this issue with the 10.1 beta that was released in December. The beta after that one is the one I believe this started to happen. STR: 1) Load http://www.hulu.com/watch/139645/fringe-olivia-in-the-lab-with-the-revolver 2) Load http://www.neowin.net in a new tab 3) Switch back to the hulu tab 4) Wait for the video to begin and watch for about 30 seconds 5) Try to switch tabs, focus the location bar or use the menu system (or try to toggle it if you're using vista or windows 7) If you can do all of those fine then keep switch back and forth between the two tabs and you should eventually have Firefox not respond to commands for at least five seconds if at all.
Just tested this with two websites one the URL in Comment 0, and another website. The problem goes away if you disable D2D/DW. Maybe it something to do with Flash's rendering size? FYI, I just seen some bugs about lib tiling rendering, but don't know if that affects this issue.
(In reply to comment #4) > I'd love to have a regression range for which nightly this broke on. Just FYI, I have seen this bug for quite some time, maybe since D2D/DW landed.
Also, I just went to Yahoo.com and it looks like this bug is there and is very slow to respond. Makes yahoo.com main page almost unusable.
(In reply to comment #8) > Also, I just went to Yahoo.com and it looks like this bug is there and is very > slow to respond. Makes yahoo.com main page almost unusable. That's bug 548985
I did notice something interesting about the process. If I clicked on the back button and click on the title bar and drag-move the window, it interrupts whatever is slowing the page down and processes the back button click by reloading the previous page.
This happens in really many sites with big or many flash objects. And this started with d2d. www.saaksi.fi is one good site to test (a webcam)...
In the newer builds, flash videos (such as those on youtube) take around 30% more CPU power with D2D enabled than without D2D enabled. Pages with flash are a lot less responsive with D2D on.
Pandora Radio is an another example of this, http://www.pandora.com/ 1. US IP addresses only 2. Go To pandora.com, w. flash enabled 3. Note major CPU usage increase 4. Note major GUI response decrease
(In reply to comment #13) > Pandora Radio is an another example of this, > http://www.pandora.com/ > > 1. US IP addresses only > 2. Go To pandora.com, w. flash enabled > 3. Note major CPU usage increase > 4. Note major GUI response decrease what type of system are you using?
(In reply to comment #14) > (In reply to comment #13) > > Pandora Radio is an another example of this, > > http://www.pandora.com/ > > > > 1. US IP addresses only > > 2. Go To pandora.com, w. flash enabled > > 3. Note major CPU usage increase > > 4. Note major GUI response decrease > > what type of system are you using? [Display] Processor: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1600 MHz) Operating System: Windows 7 Home Premium, 32-bit DirectX version: 11.0 GPU processor: ION Driver version: 258.96 CUDA Cores: 16 Core clock: 450 MHz Shader clock: 1100 MHz Memory clock: 1062 MHz (2124 MHz data rate) Memory interface: 128-bit Total available graphics memory: 894 MB Dedicated video memory: 256 MB DDR2 System video memory: 64 MB Shared system memory: 574 MB Video BIOS version: 62.79.73.00.06 IRQ: 22 Bus: FPCI Without D2D there are no issues. Also there are no issues with D2D using IE9.
That's odd, Pandora doesn't do a lot of drawing. cc'ing Bas.
blocking2.0: --- → ?
Bas, sounds like something we need to deal with one way or another. Can you have a look?
Assignee: nobody → bas.schouten
blocking2.0: ? → final+
The issue remains unchanged with the new a-sync rendering code.
Bas, can you profile this?
This appears just fine for me. CPU usage is at about 4% total. I can profile this but it doesn't seem like it would be very helpful.
Setting layers.accelerate-all to false "solves" the issue on win xp for me.
(In reply to comment #21) > Setting layers.accelerate-all to false "solves" the issue on win xp for me. That's weird, on Windows XP you get D3D9 layers which shouldn't really be relevant here.
I've just tested namoroka/minefield with this site http://www.divineproject.altervista.org/ (always with clean profiles): namoroka: after the site loaded interface remains responsive, like the other browsers minefield without Direct3D9: a bit laggy, but usable minefield + direct3d: interface "freezes", if I click a menu item it opens after 5/10 seconds...
(In reply to comment #23) > I've just tested namoroka/minefield with this site > http://www.divineproject.altervista.org/ (always with clean profiles): > > namoroka: after the site loaded interface remains responsive, like the other > browsers > minefield without Direct3D9: a bit laggy, but usable > minefield + direct3d: interface "freezes", if I click a menu item it opens > after 5/10 seconds... So, this kind of works for me in Minefield without HW accel, D3D9 and D3D10, however in all cases CPU usage in the plugin-container process is very high. I'll profile the D2D case to see if anything interesting shows up. But considering the high CPU usage is inside the plugin-container process, do you have any ideas bsmedberg?
Bug 612113 covers generic Flash perf issues which aren't correlated with particular acceleration settings.
(In reply to comment #23) > I've just tested namoroka/minefield with this site > http://www.divineproject.altervista.org/ (always with clean profiles): > > namoroka: after the site loaded interface remains responsive, like the other > browsers > minefield without Direct3D9: a bit laggy, but usable > minefield + direct3d: interface "freezes", if I click a menu item it opens > after 5/10 seconds... I profiled this site extensively on my machine (sadly the other reported sites all seem to be US only :(), couple of observations: 1. We spend half our CPU time in sqlite, I believe a bug on this already exists. 2. In PluginContainer over 95% of CPU time is spent inside the flash DLL. 3. In the Firefox Process we spend less than 10% of our time doing anything related to painting. I must say it doesn't perform poorly on this machine, but I can't see how on other machines this could cause any D3D specific issues. Perhaps things changed since the 21st. Another possibility is that the problematic behavior you were seeing is some form of lock contention rather than excessive CPU usage.
I can't say anything about the cpu usage, my comment above refers to "browser barely responds to commands" part. I have a pretty old pc (amd sempron 3000, nvidia 6150), and here firefox gains a bit of responsiveness if I disable d3d.
We'll do a little bit of investigation here using the information in this bug. We'd like to know what version of Flash was used when others saw this problem.
Mozilla/5.0 (Windows NT 6.1; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre Flash version installed: 10,1,102,64 installed Hardware specs: Intel Pentium 4 3.00GHz, 2 GB RAM. While playing movie http://abc.go.com/watch/lost/93372/257416/happily-ever-after , processor stayed between 75% to 100% load. Once tab was closed it returned to 3% to 7% load.
WORKS FOR ME While playing the movie: http://abc.go.com/watch/lost/93372/257416/happily-ever-after , the cpu usage did not go above 40 when loading and playing, does not cause spikes and responds well to commands *OS: Windows 7. Build: Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110207 Firefox/4.0b12pre Flash Version: 10.2.r152
A lot was changed recently in our plugin handling code, I'd like to know if this is still happening.
I'll give this bug one more day for someone to respond and otherwise resolve it works for me.
Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110215 Firefox/4.0b12pre I was unable to reproduce issue.
Pentium 4 3.0GHz 1.75Gb RAM, Win 7, Fx latest nightly (2011-02-17). If I turn off AdBlock+ and pause the video the flash banner on that page eats quite much CPU, so Plugin-container eats 30-35% CPU and firefox eats 9-15% CPU. If I unpause the video then plugin-container eats up to 70% of CPU. If I enable AdBlock+ and run the video then plugin-container eats about 60% of CPU, but I see a "loading..." overlaying layer above the video, so the rules for that page need some correction (abp subscriptions' issue). To prove that it is subscriptions' issue: I visit this page with ABP disabled wait till the video (not the video ads) starts and then enable ABP without reloading the page: the flash banner disappears and video plays good. Plugin-container eats about 30-36% CPU at that case. + In all cases the browser's UI stays responsive. But. On almost every youtube page I can't close the tab with a playing video until I switch to another tab or until I stop the video playback, or until I click to close the tab twice, not once. So the issue is still there.
Mozilla/5.0 (Windows NT 6.0; rv:2.0b13pre) Gecko/20110302 Firefox/4.0b13pre Not sure how helpful this information will be as it is a little inexact / anecdotal, but with the above minefield build, the video player at www.revision3.com consistently uses between 50-60% CPU while the video is playing. Each core hit about equally on my system. While the video is paused, something on the order of 15-20%. If there's something I can do that would be more precise or specific, let me know!
** PRODUCT DRIVERS PLEASE NOTE ** This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons: - it was marked as a soft blocking issue without a requirement for beta coverage
blocking2.0: final+ → .x+
It's been a while since this was reported and since then has flash been containerfied by firefox and sandboxed by adobe. Is it still a bug?
(In reply to Jesper Hansen from comment #37) > It's been a while since this was reported and since then has flash been > containerfied by firefox and sandboxed by adobe. > Is it still a bug? Can't reproduce it. Based on Comment 30 and Comment 33 I confirm this is Resolved WFM.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Issue is resolved - clearing old keywords - qa-wanted clean-up
You need to log in before you can comment on or make changes to this bug.