From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.5) Gecko/20011015 BuildID: 2001101516 Mozilla appears to still be using crufty event manager code instead of Carbon events. It sucks up CPU when it isn't doing anything, and when it is doing something like playing a flash movie it doesn't use enough CPU. Currently the only way to increase the CPU it uses is to hold down the mouse button on something other than the menu bar or title bar. This appears to cause the browser to poll for events and thus cycle its main event loop more frequently. Reproducible: Always Steps to Reproduce: 1.display a flash movie and notice the difference between holding the mouse button down and not. 2.Run the 'top' command while doing this, same conclusion. Actual Results: Uses CPU when not needed, doesn't use enough when needed. Expected Results: The opposite. Ideally when a window is active it gets as much CPU it wants, otherwise it doesn't use any. The old event manager code can't be tweaked to produce the wanted results. Instead it has to be discarded in favor of Carbon events.

Reporter, your bug report is fairly general. You refer to the need to migrate to Carbon Events in general for Fizzilla, and that is an acknowledged problem. See Bug 67409 and if you search for Fizzilla bugs with the text "Carbon Events" in them you'll find quite a few. However, it's more helpful to be specific. In this case, you particularly mention an issue relating to pages containing Flash files. So, let's steer this bug towards that case in particular. Thus editing Summary. Given these changes, I will confirm this. Flash media performance in Fizzilla is much worse than in, for example, IE, certainly WHILE THE FLASH FILE IS STILL LOADING. IE plays the animation quite smoothly, while Fizzilla manages about 4 FPS. Note: at the time of this comment, your URL is inaccessible. For the time being, I've replaced it with an accessible page. Oddly, notice that Fizzilla plays the Flash file better when it's in a regular window like this than when it's in its' usual pop-up window; visit [http://www.shockwave.com/sw/content/radiskull08] and click "Watch Film."

.

As far as I can see, all sorts of flash files are affected. The performance on a G4 2x500Mhz (OS-X 10.1.1 / Mozilla 0.96) is so slow, that some files are hard to navigate. IE5.1 is at least 200% faster in displaying flash content.

You will find OmniWeb 4.1 to be 800% faster. It's all due to Mozilla's event handling. This effects virtually everything negatively, including loading pages, animating GIFs, flash movies, completing a three way handshake (failing to open tcp connections), etc. OmniWeb 4.1 plays Flash 5 movies better because it's not polling the event manager like Mozilla is.

Currently, the plugin code installs timers that run at a period of 1020 / 60 milliseconds. That is, for every plugin instance running on the page, we end up calling EventAvail() roughly 60 times a second. This is to give animating plugins idle time. We need to switch to using true carbon event based timers, and we should use only one for *ALL* plugin instances, not a timer per instance. Also, when these timers are installed, we appear to be starving other timers with a long period. This is the culprit in bug 111982.

Patrick, should this bug then depend on Bug 106691?

Maybe so. But we should also investigate what calling EventAvail 60 times a second is doing to our performance. One would have assumed that giving flash 60 idle calls a second would increase its frame rate.

For the time being, marking as dependent upon Bug 106691.

If you want to run Flash movies, use OmniWeb 4.1sp10 or later. It's the only browser I know of which supports the Flash5 plugin and doesn't poll the event manager.

the performance of a browser playing back a flashmovie can be tested here: http://moock.org/webdesign/flash/actionscript/fps-speedometer/ interessting to see how much mozilla speeds up when the mousebutton is pressed (under Macintosh OSX)

There's no secret as to why that happens. When you hold down the mouse button Mozilla will poll for events quickly until released. The nice thing about Carbon events is they can be used independently of anything else. Thus they could be implemented in part, like for running plugins for example. I don't think the current bugreport organization serves this purpose since they have been merged into one as though ALL event manager code has to be expunged to adopt Carbon events. Of course if you use both the Event Manager will still be eating idle CPU.

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

Interesting - that speedometer. I checked and found that when running without the mouse down, we use only 8% of the CPU and do 10 fps. Holding the mouse down (we always pass 0 as the sleep time to WNE then), we jump up to over 90% CPU usage, yet the fps only goes up to 20. If we're using 90% CPU when the mouse is down, how the hell is that being spent? It probably isn't - we're just using all that CPU to pound WNE as rapidly as possible and not doing useful work in between. I think using the Carbon event model should avoid this.

Ooo... passing 0 to WNE is bad! We should not be doing that. Some time back, Apple changed it so that if you pass in 0, they set it to some arbitrary value. This was done to "penalize" those who were "hogging" the CPU by not sharing it with other processes. I expect that if you set it to 1, you will probably see an improvement.

Brian, It's perfectly legit to "pass 0" when polling for drags, which is what Mozilla is doing. Instead of fiddling with these legacy APIs it would be better to stop using them. In other words polling itself is the problem, not how frequently you do it. For example WRT plugins you can be notified of a cursor's movement when it's within a specific region (using Carbon events).

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

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

The latest flash plugin beta, at version 7.0r2 as of this writing (available here: http://www.macromedia.com/software/flashplayer/public_beta/) fixes this problem. CPU usage and framerates are vastly better with the new plugin. Can this be marked RESOLVED?

I just opened bug 217360 to investigate putting all plugin instances on a single idle timer as Patrick suggests in comment #5.

I have very poor flash performance in Firefox, so much so that heavy animations will freeze the browser and I have to force quit. Is any work being done on this?

In some cases, like in this site: http://www.ynet.co.il All mac_gecko just freeze after a minute or a little try of scrolling the page.

(In reply to comment #18) > The latest flash plugin beta, at version 7.0r2 as of this writing (available > here: http://www.macromedia.com/software/flashplayer/public_beta/) fixes this > problem. CPU usage and framerates are vastly better with the new plugin. Can > this be marked RESOLVED? I am using the latest version of the Flash plugin with Firefox 1.0 PR and visiting this site: (along with many others) http://www.somethingcorporate.com still causes lock ups. It is the same bug describe above. You can hold the mouse down and everything is fine... otherwise you can't use Firefox at all. I have to force quit the browser and restart it. This is happening at least three times a week for me since I tend to visit a lot of artist and design websites that use flash. Anyway, I don't think the latest version of Flash fixes this. It is not resolved.

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

There are a lot of "Flash is a pig on Mac" bugs. Are they dupes of this bug? bug 172312, bug 204379, bug 233702, bug 235968, bug 243901, bug 244987, bug 245032, bug 245201, bug 264664, bug 268677, and probably others I missed. Also, is there any relation with bug 238935? Last, is P.Beard really assigned, or should this be sent back to New?

This bug really should be "critical", whenever a Fizzilla user visits a page with a big enough flash file on it (which happens very frequently) the UI becomes unresponsive and a force quit is necessary (losing your place, the tabs you were working in, and any information that you might be entering into a form at the time in the same or another window/tab (found that out the hard way)). By definition this is bigger than "minor", and "major", there really isn't a workaround besides "use a different browser" or "live in constant fear of clicking on a link with a big flash thing in it" :-).

Try a camino nightly build and tell us if that's better.

Another example site to freeze the browser: http://lunarpages.com/ In a single window, open two or more links for lunarpages.com pages in tabs. The same Flash header will be on each of these pages. Within seconds, Firefox will become unresponsive; the Flash animation will stop or slow to a crawl, but will resume normal speed when the mouse button is held down. However, the rest of Firefox will be completely unusable; if you manage to get a click to close the window through, Firefox will once again become responsive. Getting the window closed is quite a challenge, though; you must click on the close button many, MANY times, and pray it gets through the lag. My best strategy has been clicking rapidly on the Firefox window close button when another app is in the foreground, and then switching back and forth between Firefox and the other app rapidly. This usually works to close the window, but on some occasions I've had to Force Quit Firefox because it's locked up.

The camino nightly build is way better than Firefox 1.0, although it still is slower than Safari, at least it doesn't crash. Will this make it into Firefox?

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

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

Is this fixed at all in FireFox 1.0.1? For me, viewing homestarrunner.com is loads better, but still a ways from perfect- with my superficial testing.. Still much slower than my wife's Celeron 400 laptop . Mac OS 10.3.8 Power Mac G4 350 704 MB ram Firefox 1.0.1

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

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

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

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

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

FireFox development team: I am a web programmer on the Mac and use FireFox for its JavaScript Console; however, due to the issues with FireFox and Flash (at least on the Mac), I will need to make Safari my default browser. It is sad that I have to turn away from a project I so much love and enjoy because you have thus far refused to fix this bug.

Is this ameliorated (any) by the CFRunLoop change?

(In reply to comment #38) > Is this ameliorated (any) by the CFRunLoop change? It should be, yes.

firefox 1.0.6 does not work well with flash-based web sites such as: www.connectionsnightclub.com i do not think that this problem is resolved. safari works fine, though. (In reply to comment #39) > (In reply to comment #38) > > Is this ameliorated (any) by the CFRunLoop change? > > It should be, yes.

(In reply to comment #40) That's because the CFRunLoop patch was applied to the Trunk. Try a Firefox nightly.

I am using Firefox 1.0.6 with Flash Player 7.0.24 on Mac OS X 10.3.9. Flash movies are pretty slow compared to a PC running Windows. My PowerBook CPU usage is very high when playing any Flash movie. When playing multiple Flash movies in the separate tabs, sometimes Firefox becomes unresponsive, CPU usage is 100% and I have to kill it. Is there any chance to see a performance and stability improvement for the next Firefox release? Thanks.

thewolf: Yes. It will be much better for 1.5. See the comments above your post.

(In reply to comment #43) > thewolf: Yes. It will be much better for 1.5. See the comments above your post. > Josh, i've downloaded FF1.5 two days ago and the bug is still there, crashes, slow (when any) playing, et al. i may add bad playing of video (rm and wm) too, but that's probably stuff for another bug.

max@corrosive.co.uk: if you crash, file a bug w/ a crashreporter stack or a talkback incident id.

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

maybe this bug is similar to bug 341380 , or maybe some of the fixes for this bug caused some king of regression described in bug 341380, which is for Windows 2000 ... Opinions ?