** Observed with 2002-06-17 Win32 1.00 branch build ** The above site and the following sites in China all consume too much as compared to IE5/6. 1. http://www.163.com 2. http://china.scmp.com/chimain/index.html 3. http://www.ccidnet.com 4. http://www.999.com.cn/ 5. http://www.chinadaily.com.cn We would like some investigation and improvement if at all possible.

All of these sites have multiple animated gif's. ImageLib creates a new image from the raw image data for each frame which is expensive. I think the performance/CPU usage could be greatly improved by caching all of the frames as offscreen bitmaps and displaying them as needed. The image decoding only needs to be done once instead of on every frame change. This would also improve memory usage since the offscreen bitmaps are kept in video card memory and the raw data could be released.

*** Bug 152732 has been marked as a duplicate of this bug. ***

*** Bug 152733 has been marked as a duplicate of this bug. ***

*** Bug 152734 has been marked as a duplicate of this bug. ***

#1, #3, #4, and #5 in comment 0 also use flash.

I tried on my linux box with mozilla, which has no flash installed, and I saw similar CPU consumption as with pr1 which does have Flash.

I retract my previous comment, I was seeing ghosts. On 163, without flash I get 10% cpu, with flash I get 87% (mozilla 1.0.0 for no flash and pr1 for with flash)

Win2k PIII-933 (w/flash) Moz = Build 20020618xx 1.0 = Mozilla 1.0 Final (20020530) 1+ = rv:1.0.0 20020618 IE6 = Internet Explorer 6.0 1. http://www.163.com/ Moz: 25% 1+ : 25% 1.0: 40% IE6: 31% 2. http://china.scmp.com/chimain/index.html Moz: 2% 1+ : 4% 1.0: 4% IE6: 2% 3. http://www.ccidnet.com/ (memory usage kept climbing in Mozilla as long as page existed) Moz: 50% 1+ : 97% 1.0: 99% IE6: 65% 4. http://www.999.com.cn/index.htm Moz: 91% 1+ : 91% 1.0: 91% IE6: 99% 5. http://www1.chinadaily.com.cn/news/index.html Moz: <1% 1+ : <1% 1.0: <1% IE6: <1%

cc: shrir, who I remember from a previous plugin meeting had issues with flash cpu usage

According to a report from China, site #2's CPU consumption went up high when the user scrolls up and down the page. The problem with site #5 has to do with memory usage rather than CPU consumption. It is reported that the memory usage went up to over 65,000K while loading the page. IE's memory usage hovers around 12,000K.

With 2002061408 trunk/WinNT on a dual PII-333 w/ 320 megs: Site #1's CPU usage seems to mostly come from the Flash animations. If I right- click each of them and set their quality to low, CPU usage drops in half. The other half is probably a combination of all the animated GIFs and some JavaScript that uses setTimeout() with a timeout of 1ms to repeatedly call itself. The CPU usage from the setTimeout() calls should be lessened by the fix for bug 123273, now appearing in a trunk build near you. Site #3 consumes memory like there's no tomorrow, and the UI gets really, really sluggish. This is probably something along the lines of one of the many bugs (bug 13350, bug 30942, bug 40848, bug 111982) where something consumes all available CPU time and something else doesn't get to happen or the UI becomes unresponsive. Site #4 makes the UI totally unresponsive (except for scrolling) -- I had to kill mozilla's process to get out. Sites #2 and #5 seem okay, with no scrolling speed problems or memory/CPU use problems.

If Flash (6) is causing this, then this could be a dup of bug 132759. Older versions of Flash may not have this problem.

confirmed these sites are using flash. Yeah, this is a worldwide problem ;).

Nominating...

One of the buggest China site, http://www.sohu.com is a killer with many flash images going at the same time. We need a solution to this problem! Otherwise, we will not be able to get people in China to use our client!

www.sina.com.cn and www.sohu.com are among the top 5 sites in China. This performance looks very bad.

Hey Kevin, no offense, but when is the last time you looked at libpr0n? Animated GIF frame caching is one of the first things we did. If that isn't working it is a serious bug. If it got changed, someone really should have run that by me... Anyway, it looks like Flash is actually the problem here perhaps in combination with another issue where we're eating memory. On the memory intensive page, is it all GIFs by chance? For the Flash pages, perhaps we have excessive reflow/repaint occuring if the problem isn't in Flash itself?

*** Bug 152994 has been marked as a duplicate of this bug. ***

"Hey Kevin, no offense, but when is the last time you looked at libpr0n?". Sorry, I had the wrong info. I was told recently that we never optimize animated gifs because they are continously decoded per frame instead of being held around as individual nsIImages. I recently fixed a printing bug where non optimized images for animated gif's where being asked to print. If all of the images animated and non animated are held as nsIImages shouldn't we be optimizing the animated gif's so they are stored in video card memory and free up main memory?

This is a dup of http://bugzilla.mozilla.org/show_bug.cgi?id=132759 This is a regression in the Flash 6 player on Windows. Shrir tells me Flash 5 does not have this problem.

Maybe it is a dupe of Bug 132759 but that bugs has been minused for topembed. This bug should be topembed.

well, we need help from macromedia on this one,no ? Arun had conveyed this cpu issue a month back to them...haven't heard of anything till now. Peter?

you know more about this than I..

Kat, I'm not getting any difference in CPU between IE 6 and 0618/1.0 on www.sina.com.cn w/ Flash 6 on WinXP. What do I need to do to see this bug? I did not install the lang pack. If you are seeing this bug, please try to remove Flash completely (rename npswf32.dll to 01npswf32.dll) and see if the CPU still pegs.

Today's http://www.sina.com.cn page doesn't have the pop-up flash ad (It useds to have a big pop-up flash ad). 06/18 builds uses a little bit less CPU than IE6. (Netscape uses about 38% while IE6 uses about 55%)

The Flash regression is known, and we are talking to Macromedia about getting it fixed ASAP. I believe that is the entire meat of this bug.

this should have been marked nsbeta1- already, this is outside the mozilla application, see bug 132759

testcase with sound : http://jazz/users/shrir/publish/flashacceptancesuite/Sound/Streaming/Kidrock.swf

With flash 5 r41 I can open all the sites in separate windows and the CPU load is in the 30-70% range. http://www.sina.com.cn/ http://ad3.sina.com.cn/ads/tcl/mobile/ http://sms.sina.com.cn/cgi-bin/sms/sms_dynamic.cgi?type=0 http://ad3.sina.com.cn/ads/icbcbj/index.htm http://2002.sina.com.cn/ http://eladies.sina.com.cn/p/zpbb/index.html http://211.157.35.9/dfac/ http://reload.w19.bizcn.com/ (sound) http://ad4.sina.com.cn/ads/wodengka/index.html http://www.nikefootball.com.cn/ http://2002.sina.com.cn/g/2002-06-01/017941.shtml http://www.chinamobile.com/qita/fifa/service.htm With Flash 6 r29 I am unable to get more than about 3 or 4 open before the CPU is at 100% and the UI becomes unresponsive.

Can at least the offending .swf files causing the 100% CPU in these pages be isolated so the site could be evangelized to modify their content?

Using Flash 6.0 d30 I noticed that the CPU load appears to be slightly higher but the UI still responded with a few more sites. Eventually, however, moz's UI stopped responding.

This is a dup of bug 132759. If you find simplified testcases which reproduce this bug without Flash, please reopen. *** This bug has been marked as a duplicate of 132759 ***

v

*** Bug 148271 has been marked as a duplicate of this bug. ***