Wednesday, September 03, 2008

On Performance

With the release of Google Chrome I see blogs and articles blaming the Flash Player for poor performance and somehow linking this to the fact that it is not open source. Time to clarify a few bits. I'll start with classic comments:

"Flash hogs my CPU!"

1. HTML != Flash

HTML is a static document format. Flash (TM) content is in its core a classic multimedia format and most Flash content is still purely passive media.

What does that mean? When rendering HTML pages CPU usage only peaks for a very short of amount of time, essentially one single frame in Flash terms. After that almost no resources apart from memory are required. If you do not interact with the HTML page at all, no CPU time is required.

How does Flash compare? Most animated Flash content like rich media advertisement continues to use CPU resources to drive animation, video and/or sound. As opposed to static HTML which has exactly 1 frame, Flash content can have an infinite amount of frames which are played back over time.

Flash is great to provide experiences you could not get otherwise. Animation, video and sound are functions the browser does not (yet) provide, or at least they are not used to the same extend yet by designers. Once the browser will be used to play the same type of multimedia content you will face the same resource usage issues. It takes CPU cycles to decode video, sound and render animation. This is just a fact of life, we are however improving how much is used release after release, something benchmarks can back up.

So, there is a fundamental difference in media type. HTML is static, Flash is not. To put it in terms you might be able to understand:

If you take a picture and print it out you use energy only once and then can continue to view the picture forever without consuming any further energy. If you record a movie you will need some form of machine to play it back which will continue consume energy in form of a projector. The Flash Player is a projector.

"You are so full of it, AJAX does not hog my CPU!"

2. AJAX != Flash, but when done correctly AJAX can be the same as Flash

In most practical instances AJAX is used to drive RIAs. Examples include Gmail, Google Maps and many others. One fundamental property of good applications is that they only respond to either network activity or user input. Peak CPU usage is limited to these events. In general, if you do not touch the browser page no CPU time is required.

Compare this again to Flash animations, video and sound which in many cases remain passive experiences with no requirement for external events to drive the content. This will obviously use CPU resources continuously.

Now, it is perfectly possible to implement a Flash RIA application (that usually means using Flex) which uses the same or even less peak CPU than a AJAX RIA and only responds to network and user input. Flash is a flexible multiple paradigm platform, it depends on what the designer/programmer wanted to do. Unfortunately we at Adobe tend to see of a lot of RIAs which do not follow that principle and add lots of moving sugar to their applications which do little to improve actual usability.

Following good coding practices Flash can yield equivalent or better results than AJAX for many types of RIAs. Another benefit is that writing RIAs in Flash is truly cross browser as there is one Flash Player implementation only.

"Bull, SVG and Canvas show that it can be done better"

3. SVG/Canvas != Flash

Have you ever seen SVG or the canvas tag being used to implement anything else than static (1-frame) content? Have you ever seen rich media advertisement done using SVG or the Canvas tag? I mean not some demo page but actual deployed content. If so you will realize that the same resource usage issues apply.

"You are clueless, why does Flash suck up CPU time when it is on a hidden tab?"

4. Easy shortcuts do not work

Believe it or not but we and the browser vendors have tried to disable/pause/stop Flash content when a tab is hidden. The results were disastrous user experience wise to say the least. Disabling Flash to get any benefit CPU resource wise means the following:
  • Sound will have to stop
  • Any network transfer will have to stop
  • ActionScript execution will have to stop

Each one of these affect CPU resource usage and would affect user experience if we would turn it off. However the Flash Player does not render anything if it is on a hidden tab, we only execute the operations mentioned in the above list.

There is one exception to the rendering optimization: WMODE. If you use WMODE the Flash Player has no way of knowing if it is hidden or not and will continue to do a full render. Do not use WMODE. Unfortunately lots of rich media advertisement I see out there continues to enable this for no apparent reason.

"Flash sucks!"

5. You can help to educate web designers so common mistakes are not made

Huge help would be to adopt strict policies especially for rich media advertisement. I like the rules Google has put forward for Flash ads. Quoting:

"Animation Length: Animated ads are restricted to a maximum of 15 seconds (at a 15-20 fps frame rate), after which point they must remain static. These ads must also comply with the other animation policies."

Personally I would go even further and request the following:

  • After the animation has played no CPU resources should be used, ActionScript should be on a stop() command.
  • Mouse tracking or other event handling is not allowed unless you activate the banner with a mouse click.
  • DO NOT USE WMODE UNLESS YOU ABSOLUTELY NEED TRANSPARENCY! I can't stress that enough. Given the architecture of plugins there is no way for the Flash Player to know if Flash content is on a hidden tab or not and disable rendering properly. If you use WMODE the Flash Player will continue to suck up CPU cycles as if the tab was visible. In addition WMODE is much slower than the normal mode.
These simple rules would address almost all the complaints we hear about. Adobe has unfortunately only limited influence on what content gets deployed, in this case it is really up to the community to balk at the web sites putting up content which impacts user experience negatively.


Like with any powerful technology it is easy to shoot yourself in the foot and with the ease of use of Flash that is unfortunately too common.

Despite of that we are working with all browser vendors to improve performance and user experience whenever possible. There are differences between browsers and our goal is to close this gap once and for all. We are for example looking forward to work together with Google to improve Flash performance in Google Chrome.

On our (Adobe) side we are also looking forward to improve Flash performance further. Flash Player 10 for instance is making the first steps towards hardware accelerated rendering which will provide a huge boost in rendering performance. On the scripting side Tamarin-tracing will improve scripting performance dramatically. This is work we share with the Mozilla foundation which will use the same core libraries under the TaceMonkey project. The latest benchmarks are quite remarkable.


Blogger sascha said...

Aah the Flash-Hater Crowd again! Always amusing! But have they ever mentioned that Google obviously has perma-rented the term' Beta'? It seems most things from Google are beta ... forever! Take Google Earth. it's now version 4. And it's still beta. Google Docs ... beta! GMail, yes! Beta! Of course so is Chrome! Let's see how long it will be beta! 4 years, 10 years, a lifetime?

I'm glad Adobe takes their job serious and develops decent NON-BETA software! And Flash Player is a small wonder on it's own!

Thursday, September 04, 2008 9:36:00 PM  
Blogger art said...

Is my understanding right here: In chrome, every tab runs a separate process. But the Flash Player is single threaded. So each "Flash active" tab will degrade the performance overall but AJAX/HTML will not suffer from this. Does this sound right ?

Thursday, September 04, 2008 10:30:00 PM  
Blogger sysadmin said...

I'd like to see a working flash player on FreeBSD.
Can you give us more details about this?

Thursday, September 04, 2008 11:30:00 PM  
Blogger Kevin said...

One thing that Adobe could do which might help is to have the player actually react on the actions its context menu provides, e.g. stop looping when "Loop" is unchecked or stop playing when "Play" is unchecked.

Like browser stop animating images when their "stop animation" action is triggered by the user.

Friday, September 05, 2008 12:59:00 AM  
Blogger oggologgo said...

Pages with flash completely freeze google chrome for several seconds, periodically. Not just on tab, but the whole browser.

Since this problem does not occur in any other browser, the fault cannot be flash, but purely chrome.

Friday, September 05, 2008 2:57:00 AM  
Blogger tomsamson said...

If using wmode is so bad, why does Adobe actively support the thought of using it by adding gpu support only with more new wmode params passed?

Friday, September 05, 2008 4:19:00 AM  
Blogger dmorrow said...

To be very clear, I'm definitely not part of the 'flash hater crowd'. I'm a long time flash dev, and we all have to admit that flash sometimes takes up too many cycles, or at least more than we would like. Rather than defensively saying "HTML != Flash", I would hope for more ways that you are going to make flash play nice.

Skipping banner ads, which are more often than not horrible and not developed correctly, lets talk about sites that use flash extensively for content. Large sites use flash as part of a large ecosystem - they can't be just flash. It's great that flash has gotten to this point, but we need to recognize that sometimes it doesn't work as well as we might hope. I'm not talking only about video or using papervision. Obviously those are CPU heavy things that can push flash to the limit and max the processor. I'm talking about 'basic' content modules in flash, RIAs, whatever we want to call them. Sometime having flash on the page makes performance drop - even when flash is doing nothing big in particular.

WMODE - because using WMODE is the only way to have html (menus, etc) float above flash, we are often forced to use it, even if we don't need the flash transparent. This is a big issue. And saying "don't use WMODE" doesn't recognize how people expect flash to behave on a page. Ideally, it would act like any friendly html element. I know there are many technical reasons why this isn't easy - but that's a big part of the issue here. This is why banners are often transparent as well - the developers don't know what site they are going to be on and where they are going to live on the page.

Tabs - Maybe there needs to be an event for when a tab gains or loses focus. It is understandably hard to globally "turn off" flash when a tab loses focus, since every flash app is different. However, as developers, we could make those decisions easily.

I think you're doing a great job - and flash just keeps getting better. But just as people shouldn't blindly say "Flash hogs my CPU!", its not best to respond "Flash FTW - its the nature of the format and actually it the developers fault for messing it up"

Friday, September 05, 2008 4:30:00 AM  
Blogger Holger said...

Hi Tinic,

interesting post on Flash. I have to admit, I am not much of a flash fan. But that is more due to wrong usage of Flash than to the technology itself (as I don't know enough about developing in Flash). Many websites use it for unnessary things and creat a website with bad usability.

However, you mentioned WMODE should not be used. At the moment we do not see any alternative. Let me describe the problem. We deliver certain messages on different websites (no ads) where the user can choose what to do next.

This is done via a layer which has to be on top of any element of the website (we are inviting the user to give us their opinion). User can accept a certain action, they can decline or simply close the layer. However, of our clients' websites use flash, so we currently ask them to enable the WMODE, otherwise our layer may appear below the flash content and can not be used or seen properly.
We would happily avoid the WMODE, if we would only be able to get the layer on top of flash content any other way.


Friday, September 05, 2008 5:00:00 AM  
Blogger The_Guest said...

Peoples ignorance never fails to amaze. I must say great job on great work, your efforts to improve this medium and always impressive.

I think all you can do with people with their opinions, when they want to enforce it, is tell them to think before they speak. Or at least do some light investigation. The amount of hype this release has generated in an online community ranting about the vast improvements to so many aspects of the player outweighs this ignorant whisper on the ether trail.

Thanks for clarifying this confusion for people, will be linking this!

p.s. I'm viewing your blog in the fox(@100%) and have to tell ya, the fonts a little bit tough to read, sometimes the spacing on letters confuses words or characters seem degraded. Either way just thought to bring it to your attention.

Friday, September 05, 2008 5:16:00 AM  
OpenID rajaka said...

Tinic, let me correct a little misprint in the end of article: you wrote "TaceMonkey", I guess you actually meant "TraceMonkey".

Thanks for the great article!

Friday, September 05, 2008 5:16:00 AM  
OpenID rajaka said...

Here's the most recent chart on TraceMonkey performance from Brendan Eich. Very promising.

Friday, September 05, 2008 5:19:00 AM  
Blogger The Saj said...

"AJAX/HTML will not suffer from this."

Don't know the answer to that one. What I do know, is that Chrome breaks many AJAX/HTML apps. For example, Netflix's queue does not work.

And that is a significant problem of AJAX based systems. A new browser must be "compensated" for.

Friday, September 05, 2008 5:47:00 AM  
Blogger E$ said...

BETA will be done in Web3.0. Flash will still be there because Flash helped changed the internets ( web1 and web2 ).

Great article!

Friday, September 05, 2008 7:48:00 AM  
Blogger Raymond said...

Excellent article, regarding your point on browser compatibility

"Another benefit is that writing RIAs in Flash is truly cross browser as there is one Flash Player implementation only."

I was wondering if you were going to do anything about Gnash? After all it has been constructed by stealing your code through recompilation (Yes the author states this). Its truly unfair that after all the time and money you have invested in the flash player the FSF can decompile the code and without paying a penny slap on a “100% free software” sticker and call it their own .

Gnash presents a huge threat to flash developers by introducing variation into the player just like the variation that plagues JavaScript. I certainly don’t want to have to support this player just to suit some twisted definition of free software.

I’ve only been employed for a short time as an actionscript 2 developer ( and I’m looking forward to a long career as a flash developer. But Gnash could change all that by taking everything that’s good out of flash.

I sincerely hope that this theft of code will be dealt with ASAP for the good of the entire community.

Friday, September 05, 2008 7:57:00 AM  
Blogger circlecube said...

Great article, thanks for all the good work!

Friday, September 05, 2008 1:47:00 PM  
Blogger Duke said...

We do extensive flash and flex development. I am not a flash hater. I am a bit fan of flex and flash.

And at the same time I believe the actionscript performance is very average - at best. This is made worse by some elements of the Flex framework being very slow - such as the advanced datagrid.

Adobe's line that Flash/Actionscript is "10 X faster than previous versions" means nothing. Actionscript is slow and Adobe should fix it.

Adobe's denials that Actionscript is slow is simply politics.

I'm glad to see that the rest of the industry is creating dramatically faster javascript interpreters. Hopefully this will prod Adobe stop stop denying the poor performance of Actionscript and fix it.

Adobe hopes that constantly saying that Actionscript is fast will make it fast.

Friday, September 05, 2008 4:13:00 PM  
Blogger makc said...

I dont know why, but I think if swf that runs fine in FF or IE, freezes up and then crashes Chrome, it's Chrome problem and not swf problem.

If they are going to force us to develop flash content that does not freeze Chrome, I quit.

Saturday, September 06, 2008 6:13:00 AM  
Blogger Tek said...

Let people discover the web with Javascript, one day they will discover Flash...

Thanks to help them Tinic !

Saturday, September 06, 2008 7:49:00 AM  
Blogger gludion said...

hello, nice article.

Do you know why the flash activeX reduces the framerate by 20-50% in comparison with the standalone player?
It's not really related to bad content: it happens even if the movie is empty (except a script measuring actual framerate).

Sunday, September 07, 2008 10:23:00 AM  
Blogger space said...

why is it so slow on mac compared to windows? i've seen no improvement in any version so far. are you doing anything in this regard?

Monday, September 08, 2008 7:20:00 AM  
Blogger Si said...

"And at the same time I believe the actionscript performance is very average - at best. This is made worse by some elements of the Flex framework being very slow - such as the advanced datagrid."


ActionScript isn't slow, and ActionScript 3.0 is about 10x faster than previous versions thanks to the new VM. The thing that holds back performance is vector rendering, especially if a lot of gradients and/or transparency is used. To get the most out of Flash you need to know how to optimise the rendering, and code optimisation can also help a lot.

Thursday, September 11, 2008 4:36:00 AM  
Blogger Runtime said...


Flash seems to be the culprit in Google Chrome - any time I go to a flash page, and try scrolling while a video is playing or something like that, the browser locks up for like ten seconds.

This happens primarily with flash pages. When it does happen with other pages, it's not nearly as bad as it is with flash.

Saturday, September 13, 2008 4:58:00 PM  
Blogger Si said...

If Flash runs ok in Firefox and Safari then it should run ok in Chrome because Chrome is built on Firefox/WebKit code. Occam's razor would suggest the problem is Chrome, not Flash.


Sunday, September 14, 2008 1:38:00 AM  
Blogger POTOK said...

The mac version of the player is terrible compared to the Windows version! That problem has been present in every mac version to date.

Sunday, September 14, 2008 6:27:00 PM  
Blogger Cosmofilia said...

I'm not sure why Adobe provides context menu controls for Play, Loop, Rewind, Forward, and Back, but no option for Stop Running. Obviously Adobe knows that Flash has become more than just animated banners. Why haven't the content menu controls followed suit?

I don't buy the argument that content authors are uniquely responsible. It is unrealistic to expect EVERY developer on every project to adhere to Adobe's or anyone's design guidelines, to build functionality for intelligently throttling CPU utilization, to check their projects with code analyzers, or to test their apps on all major browsers and platforms.

There will always be some Flash apps that misbehave, intentionally or not, and the Flash Player would be wise to provide a basic "close" action, just like every modern operating system allows the user to close any application, malignant or benign.

Google's philosophy with Chrome doesn't fully address this, either. Closing a tab containing an uncooperative Flash object is better than closing the entire browser, but what users really want is to close the offending Flash object. There may even be other "good" Flash objects on the same page, from authors who know nothing of each other. Combining foreign content on a single page is commonplace, and even promoted by Web 2.0.

The Flash Player user controls are painfully outdated, and are virtually useless in a world inhabited by Flex, Air, and Actionscript 3. The fact is, user experience is suffering and it is within Adobe's power to fix it.

Tuesday, September 30, 2008 7:14:00 AM  
Blogger Brian Sexton said...


And we, developers who are forced to use WMODE to get Flash content to render below other content on Web pages (e.g., Facebook chat overlays), cannot stress enough that we have no viable alternative. That is why I am posting this even though at least two other comments already mention this issue.

Monday, October 06, 2008 9:16:00 PM  
Blogger Nobody said...

Uhh... Okay, I have a genuine complaint about performance, and it contradicts what you said in your post. Flash never idles. In fact, it's much worse, at least in NPAPI browsers (Fx, Chrome...). Any Flash object will trigger over 1000 context switches per second. Even if it's static, has no sound, is not visible, etc...

This is a sign of a terrible design mistake: somebody doing a sleep(1) or setting timers for as a short interval as possible. I don't know whether it's a NPAPI limitation or some cruel bug, but it's heinous, as it burns over 55 Core2 MHz per Flash object present (it might not show as % CPU usage because of sampling artifacts - unless an app uses its full timeslice, CPU usage isn't counted against it [I'm talking about Windows, obviously] - however, get 30 Flash objects loaded and CPU will be at 100% no matter what).

Moreover, the default Windows system clock is 100 Hz, but Flash goes ahead and calls timeBeginPeriod(1) to raise it to 1000 Hz. I understand this is desirable to reduce jitter on animations on multimedia stuff, but here it just exacerbates the problem.

This getting fixed would make a world of difference on pages that use flash just to display some graphics elements without animation or interactivity - and a big difference in general. I have a feeling it'd need cooperation from the browsers though, but I don't think they'd mind cooperating.

If there are places where I can report this as a bug formally, don't hesitate to tell me.

Wednesday, October 08, 2008 1:17:00 PM  
Blogger John said...

WMODE is what IMO causes the most problems, there are certain ads that are animated at 100fps and use WMODE creating terrible performance problems.

However, while I can see where the problem comes from, I don't think it's unsolvable. Surely the browser knows whether the plugin is actually visible or not, I'm sure there could be some kind of callback where the browser told the plugin "you're not longer visible, stop drawing" and "you're visible again, start".

Just because the current API can't do it doesn't mean it can't be improved with some sort of extension.

Monday, October 13, 2008 2:41:00 PM  

Post a Comment

<< Home