Flash in background windows in Safari: Why is it slowed down?
Posted by Pierre Igot in: MacintoshJanuary 4th, 2006 • 11:56 am
There is one thing that I really do not understand about Flash animations in web pages loaded in Safari windows: Why do these animations slow down whenever the Safari window that contains them is in the background?
It’s not like Mac OS X is not capable of handling animated visuals in the background in real time. After all, to illustrate Mac OS X’s capabilities in that department, all you have to do is go to System Preferences, open the “Desktop & Screen Saver” preference pane, and go to the “Screen Saver” tab. Then just select one of Mac OS X’s slick built-in screen saver animations, and watch the preview in the “Preview” area of the window.
It’s a high-definition preview playing smoothly in real time. Now leave this preview running and switch to another window in another application. Mac OS X continues to play this preview smoothly in the background just fine.
Why can’t it do the same with Flash animations in Safari windows in the background?
Don’t get me wrong: I don’t particularly like animations on web pages, and I really do wish that Safari would include a built-in feature to turn them on and off reliably. (There are contextual menu commands for this when you control-click on a Flash animation, but they don’t really work reliably.)
But what is the rationale behind this particular behaviour with Flash animations in the background? It can’t be because they demand too much CPU power, can it? If that were the case, then I can think of lots of unnecessary built-in behaviours in Mac OS X that waste precious CPU cycles and that Apple should at least provide users with the option to turn off, like the high bouncing icon in the Dock when a background application requires your attention.
And this slowed down behaviour doesn’t prevent the Flash animations from being distracting either. If the objective here is to make them less distracting, it would be better to make them stop altogether.
It’s not a problem with the Flash plug-in itself either. Camino, for example, uses the same Flash plug-in, and doesn’t exhibit the same behaviour. It continues to play Flash animations smoothly in background windows just fine.
I just don’t understand.
January 4th, 2006 at Jan 04, 06 | 3:11 pm
I can’t tell you why, but I can see how … in the WebKit source, in WebKit/Plugins.subproj/WebBaseNetscapePluginView.m, null events are sent 50 times per second when the window is active (“key”), and only 4 times per second when the window is inactive. There’s a special case in there for dashboard to keep sending the high frame rate, too.
Perhaps this could be submitted as a bug report to BugZilla …. I think it would be nice to have this frame rate be something settable with a preference, at the minimum … I don’t like that it’s hard wired into WebKit.
January 4th, 2006 at Jan 04, 06 | 3:19 pm
Isn’t Camino based on WebKit as well?
January 4th, 2006 at Jan 04, 06 | 6:50 pm
I assume it’s a performance optimization. I have no idea how Macromedia has implemented the Flash plugin on OS X, but if it can’t be smoothly offloaded to Quartz Extreme and/or Core Image (as I assume the screen saver preview can), then it could be a huge performance advantage.
Camino is based on Gecko (like Firefox). (OmniWeb and Shiira use WebKit, as do a bunch of non-browsers-with-integrated-browsing, such as NetNewsWire.)
January 5th, 2006 at Jan 05, 06 | 8:42 am
Right, I got things confused. Thanks for the clarification.
January 5th, 2006 at Jan 05, 06 | 1:57 pm
My guess this is an optimation because of the high CPU usage flash plugin and probably some other plugins. Bouncing an icon in the dock is nothing compared to the CPU usage of some flash ads or games. A single (probably poorly made) flash ad can take tens of percentages of my Powerbook’s CPU capacity not to mention what happens when I have tens of pages open, which is quite normal for me.
This is actually the very reason why I am not using Camino, it just takes too much of my precious CPU when I have several tabs/windows open at once.
The compromise Safari is making may not be the optimal for everyone but adding an option for this kind of things in Safari is probably not along the lines Safari should be, a simple, easy and fast browser for normal users. An option for this in WebKit could make sense for developers.
January 5th, 2006 at Jan 05, 06 | 2:14 pm
I find it quite amazing that Flash animations can take up some much CPU power, but I guess it’s possible.
That said, if Apple were really concerned about this, they could take some very simple steps, like providing a sure-fire option to stop the animations altogether. It seems to me that the Flash animations encountered by most “normal” web users are unwanted ads 99 percent of the time. How about a simple option like the one provided by the freeware SafariStand? It makes loading Flash animations (if desired) a simple one-click option.
Also, don’t underestimate the amount of processing power required by the high bouncing icons in the Dock.It’s only now that I have a G5 Quad that I actually don’t feel the impact of it (but I still find it a highly undesirable visual intrusion).
January 5th, 2006 at Jan 05, 06 | 10:31 pm
Flash has been very CPU hungry on OS X although the matter seems to be getting better. I would guess the development is because optimizations in both OS X and the plugin. Perhaps also the browsers.
I could have been underestimating the CPU hit of bouncing. But let’s do a quick measurement! I used Colloquy to get an icon to bounce repeatedly on the dock. It seems that while the icon bounces Dock takes about 0.4% CPU. Rendering this flash animation (when scaled to a reasonable size takes about 30% . The measurements have been done with my system (10.4.3, 1.33GHz powerbook) using my current settings so your mileage may vary, but this result seems to indicate that the price of bouncing is rather small compared to some flash animations.
I admit that the animation chose is probably not your average flash animation but worse in this regard.
January 6th, 2006 at Jan 06, 06 | 9:40 am
It would probably take much more than a single experiment with a specific hardware combination to determine the actual impact of high-bouncing icons on overall system performance. I have been complaining about this high-bouncing effect for a long time. On my old G4/450, the system was unusable when the icon was bouncing. On my next machine, the dual G4 1.25 GHz, the system was usable, but you could definitely feel the effect while typing text in an application such as Mail or Word. There would be small delays in the flow of typing, which would interfere with self-correction in a very real way. It’s only now that I have a G5 Quad that I don’t notice an impact on other activities. Maybe it has to do with the graphics card in the machine. (The G4 MDD had a Radeon 9000.)
I also suspect that the CPU sampling frequency of the Activity Viewer or
topcommand in Terminal make them only imperfect tools to measure the actual impact of such behaviours on performance.Even with no impact on performance, I still find the behaviour unnecessarily intrusive from a purely visual point of view. But that’s another debate…