Plug-in Performance - SWF or Flash Player?
DIGG IT!
16
Comments
Published
Wednesday, September 03, 2008
at
2:19 PM
.
During the cartoon release of Chrome yesterday there was a funny page on plug-ins that really didn't represent ... hmmmm ... well reality. The question is really who is to blame, the plug-in or the content it is playing?
With programmatic plug-ins (Flash Player, Java, Silverlight) this gets really complex.
In Flash Player it works like so:
1. Browser instantiates Flash Player.
2. Flash Player is passed a SWF file.
3. SWF file leverages capabilities/APIs of Flash Player.
Now #1 and #2 are clearly things that Adobe should be 100% accountable for. If these are not fast, easy, and seamless, we need to fix them end of story! On the same hand though it is great when browser creators actually work with the Flash Player team because they can and do work wonders. We are very committed and open to making sure Flash Player works everywhere. :)
The question then is a matter of content, SWF. What is a particular SWF doing to Flash Player and how is that in turn affecting overall performance. As a developer, I can make Flash Player consume a ton of memory loading images into memory or loop very fast drawing pixels, 3d content, or any type of video or graphic or I could also choose to very carefully architect an application and build something high performance using a minimalistic approach. Content for Flash Player can be well architected or it can be very sloppy, but isn't this also true for every programming or scripting language. I am not sure Google intended to say Flash Player is to blame but Flash Player does get a bad reputation for content that is developed poorly or where APIs are improperly used.
Everyone can attest that there are some amazing uses of Flash Player out there (Youtube, Google Finance, HULU, Picnik) and there are some that really push Flash Player to its limits (Exhibit A).
So lets place "BLAME WHERE BLAME BELONGS", and realize that a majority of the time SWF content is to blame and not Flash Player.
My performance rule of thumb:
Flash Player will do everything you ask it to do, so be careful what you ask of it.
If you ask Flash Player to "download the Internet", it will try its very best under it's security sandbox rules to complete the task. That is all anyone could ask from a programming platform, do exactly what I tell you to do, no more, no less. It would be ideal if we could point the finger at the content causing the problem vs blaming a plugin.
The thing that keeps me up at night is that Chrome just gave every browser company license to innovate. Apple, Microsoft, Mozilla, Opera are all obligated to change their implementation and throw their hat into Browser War 2.0. Google just took browser compatibility and turned it into an active warzone of change. I think we are in for a wild ride here.
Technology aside, I really like that the OS and the browser are wearing combat boots and that plug-ins are wearing sandals. Also since when did plugins get larger than the OS or browser in overall size.
Is that plug-in eating cake? I like cake!
Cheers,
Ted :)
Let's make it clear with one minor, but important correction, Ted:
'Flash Player will do everything you ask it to do' IN A SINGLE THREAD.
Load 5000 records in a DataGrid and click a column to sort it. The plugin hangs. Who's to blame? The content or the plugin? Is it the Flex developer's fault to not know that Flash will use the same thread to process sorting as it does for rendering? Or perhaps Adobe should've done a better job with architecting the plugin?
What it is really slick is that chrome breaks the adobe deep linking javascript and history management. In the past this is not something I had to worry about except in the case of opera which I don't care about anyway. However google software seems to make onto a lot more machines than opera.
I like sandals and cake. :) It'll be interesting times coming up for sure!
Anonymous,
Not exactly. :)
Flash Player is multi-threaded and various features use threads, networking, rendering, and others. It is true to say the runtime execution model is a single thread of execution.
The problem with sorting 5000 records in a datagrid is that you are forcing the sorting over a single keyframe. This locks up the UI and makes things look terrible. There is an easy way to fix this using mx.core.UIComponent.callLater and sorting should be changed in the Flex framework to support cross-frame sorting logic.
Actually the C/C++/FLACC compiler work by Scott Peterson implements a green threading model at runtime that makes working across frames very easy. Actually it is so good that he was able to implement the Quake engine running at 60fps in FP10 and implement other programming languages in player (python, ruby) at runtime without issue. It is way fast and has really changed my take on the lower level player architecture.
To simply point to lack of threads in player here is a mistake. There are good ways to solve the problem at hand today and there will be really great APIs added for better solutions tomorrow.
Perhaps anonymous posters that work for MSFT should stop trolling my blog complaining about threads. :)
Ted :)
Ted,
Why not implement something similar to the task manager so in the context menu or something you can tell the system the exact breakdown of resources being consumed by the flash player?
Then that allows you to pass the blame one more rung down the chain.
For Google:
Web apps >>> Desktop apps
And when it comes to web apps:
HTMl/JS >> Flash
They have a lot of open source projects based on these principles: Ajax APIS, GWT, Gears, and now Chrome.
Their cartoon is simply FUD . Chrome is not a breakthrough in terms of speed (rendering, JS, or CSS.) It is a memory hog courtesy of all the processes it spawns. The extra features it supports are irrelevant because web developers are always stuck developing to the lowest common denominator (and that would be IE6 still.) So what do you do when your technology falls short? Marketing baby, marketing.
'Flash Player will do everything you ask it to do' IN A SINGLE THREAD.'
Processors have been operating with a single thread of execution for many years and programmers have had to deal with this. It is only recently that we have had dual-core processors and even then all you are doing is time-sharing those processors. If you don't share "nicely", you screw up the system for others.
Many people coming from a Flash background through to programming have had the luxury of not needing to worry about this too much in the past, but if you want more power to your plugin, you have to accept the responsibility and learn how to program fast routines, etc...
Although the framework has some responsibility for playing nice too - if you want super slick stuff, you may have to custom code and work within the confines of the system.
As a crude analogy - just because a Formula 1 car is fast does not mean you can drive it fast, you have to learn how to drive it.
Tried mx.core.UIComponent.callLater, still the same [hanging] effect. Do you have a sample code you could share? Also, based on everything you said, is there anything a developer/application user can do today to avoid the single threaded execution issue? I hear a lot of promises, but what can be done today? Or perhaps you're running for president too?? :)
Btw, I do not work for MSFT, however I have seen enough prospects going with SL just because of the threading issues with the Flash plugin.
Can you post the code you are using first? I would like to see what you are seeing.
email it to: ted@adobe.com
Please avoid attachments :)
Happy to help. Might make for a good blog post.
Ted :)
While the subject of multi-threading in Flash is a bit off topic from the original post, since it's been brought up, I do hope in the future that we might see the Flash UI on a separate thread, or if that's not possible, then perhaps some sort of green threading framework introduced into Flex.
Pixel Bender gives you multi-threading for math equations, but it's still limiting.
As Flash and Flex applications get more and more complex, I think this is going to become a bigger and bigger issue.
However, instead of just complaining about it on Ted's blog, a more pro-active approach would be to vote for the feature request in Adobe's Bug and Issue Management system.
Here's 3 locations where I've seen it pop-up:
ActionScript Compiler:
https://bugs.adobe.com/jira/browse/ASC-3222
Flash Player:
https://bugs.adobe.com/jira/browse/FP-93
Flex SDK:
https://bugs.adobe.com/jira/browse/SDK-11601
Unfortunately, not too many votes or comments for these features just yet, so hopefully people like the Anonymous can push up the vote count, so that we can perhaps see this in Flash Player 11 and/or Flex 5.
As for dealing with these problems today, there a number of posts in the Adobe blog feeds dealing with various different techniques for pseudo-threading (aka green threading) in Flash. However, it would be cool to see perhaps some sort of framework perhaps developed by the community until a solution is available from either the Flash Player or the Flex framework.
SilverFish developers come from a Front Page Express background. :)
I don't think all of the blame should be put on developers here. I realize developers can do things like create their own layout management and reduce binding to help performance.
There are times though where the flash player goes crazy if an application is left open to long. It starts using up to 20% - 30% of the CPU but if you pause in the debugger it is just on the Timer/tick which means none of your code is executing.
I love Flash/Flex but I think the flash player still has a little bit to go before it can claim 100% garbage in garbage out.
You may have mad a distiction without a difference. Most developers are aware that the leanness of their code translates to better performance and a better user experience. End users, though, don't.
Maybe the answer is for Adobe to give the user more control of the Flash Player. Maybe something in the settings panel that lets them limit how much CPU and memory the Flash Player is allowed to use.
Adobe could also do a better job at giving developers tool to manage memory and CPU cycles. The famous garbage collection Grant Skinner brought light to is an example. The profiler tool in Flex Builder is a useful tool but a. it's only in Flex and Flex Builder, b. it costs you an extra $400 upgrade, and c. it's good at identifying problems but not how to fix them.
Jamie
Speaking of responsibility on Adobe's part for Flash Player performance: what's going on with the performance divide between the player on OS X and Windows?
Using VMWare or bootcamp, an identical Flash/Flex app running in OS X gobbles far more CPU than the same app on Windows. This happens when the app is running inside Flash in the same browser on both platforms, so I can only assume it is the Flash plugin that is to blame.
Is this something Adobe intends to improve? Or will we just need to get used to worse Flash Player performance for equivalent apps on OS X for all time?
Thanks,
- max
Hey guys, you are developers! So is your job to make a good release and dont complain like 'its not my fault its the flash player' that terrible! Dev is not so easy.
And I am sure if adobe add multi thread support, you will complain like 'why my thread never stop!Why my browser crash?'...
You can use callLater function or setTimeout and deferred all heavy work, flex has a lot of ways to do that.
"Perhaps anonymous posters that work for MSFT should stop trolling my blog complaining about threads. :)" Sounds a bit paranoid.
Anyway, I think callLater would only let you separate the rendering from the errant code. You write a loop and Flash will become unresponsive while you're in that loop... even if that loop doesn't begin until the callLater part does.
But as has been pointed out, you can put your code in an interval or timer and break the loop out so it doesn't cause the player to hang.
Ultimately, I agree with "tom"--you have to write code to overcome these sorts of issues. Sure, I can point out various gripes about Flash player and it's nice how it keeps improving... but it's not like we're all so lame that we can't produce anything good until every detail is perfect--that will never happen with any technology.
Anyway,who says that fat plugin is supposed to be Flash? Seems like you could make an argument it's actually the gears thingy.
And, why doesn't JS get a mean icon too? I mean, sure their V8 engine is just perfect but, really, it's still JS.