and the award for the biggest linkbait title goes to ...
I was pleasantly surprised when I seen my HTC Desire running flash, but then after a few weeks it just got annoying and I turned it off, battery performance went up, and I have not once had an inclination to turn it back on.
It's easy to understand where the annoyance comes from.
There's a big difference between comparing a "good written" flash thing which you make yourself and having the flash enabled while browsing the web. With first you can demonstrate Flash's superiority, with the second you're picking up all the incompetent code written by anybody and almost 100% of it is used only to make something totally unimportant just moving to get an attention from you.
When we consider Flash as the content delivery mechanism and not the movement based attention taker we're left only with videos and games on the web. But both should be optimized for mobile. For video, transcoding is needed. For games, better writing them native.
Just wait till all those incompetently written advertisements, video players, etc. are all written using HTML 5 standards. Pretty soon we'll all have an extension in our browsers called "Canvas block".
Would blocking canvas be even enough? Or would we need "HTML5 block" to avoid constant annoyance? And what's going to happen on all these devices where we can't install extensions?
That's why I intend to use Opera Mini as long as it works.
I second this. In fact I always find comments along the lines of "I tried Flash but then uninstalled it" curiously suspicious: It is very common knowledge that it should be set to ondemand, as otherwise you will drown under a sea of hundreds of heavily animated advertisements.
I have it on ondemand, and while I seldom enable it, when I do I appreciate that I have the option.
The problem is Apple hasn't enabled hardware acceleration for Canvas on Mobile Safari. If this demo was instead using CSS transforms and animations, which are hardware accelerated, it would run locked at 60 FPS no problem.
Hardware acceleration for 2D Canvas would be nice to have, but what would be even better is WebGL. That would blow Flash out of the water for sure. WebGL was recently enabled by default in Firefox 4 nightly builds so it's looking like a lock for the final release; hopefully Apple and Google follow suit.
Both. I could be wrong, but I don't think this particular demo uses Flash's hardware acceleration support. I'm not surprised that Flash's software rasterizer is faster than Apple's Canvas.
Yes. Hardware acceleration is available in Flash10.1 for Android. Flash leverages on hardware acceleration only when absolutely needed( for H.264 decoding etc ).
As a simple ball bounce animation, i dont think hardware acceleration kicks in during this demo. With all the html5 love Apple is showcasing (apple/html5), they should have enabled hardware acceleration for html5 long before.
They did enable hardware acceleration for some parts of HTML5 (and it's quite impressive when used), just not for Canvas. They're not alone; no implementation of Canvas was hardware accelerated until IE9. If you ask me, hardware acceleration of Canvas is a no-brainer, and it should have been in the very first implementation. It's frankly embarrassing that it took IE9, of all things, to make browser people realize that graphics hardware is orders of magnitude faster than software rasterizers, and that's important.
Is there some reason to expect one to be faster than the other? Each is essentially JavaScript plus vector graphics. Some particular implementations might suck more than others but they are ultimately the same sort of technology.
If anything, I would think that Flash has the potential to be faster since it was designed from the beginning to do only what it does, whereas <canvas> is an extension to the already massively complicated technology blob that is HTML.
Both languages are essentially ECMAScript, but ActionScript (3) is static and JavaScript is dynamic. Java is faster than ruby/python etc and ActionScript is faster than JavaScript.
Both ActionScript and JavaScript are based on ECMAScript. However given equal environments (access the hardware exceleration or not) ActionScript will always be faster because it uses strong typing and at then end of the day is compiled into a SWF.
That article forgets that it only applies to relative performance comparisons. Frames per second is still a perfectly valid and useful unit for measuring the performance in an absolute sense: 24fps is just barely enough to be perceived as smooth animation by some people, but 40fps will be perceived as smooth by almost anybody, and and at 57fps, you're closing in on the limitations of consumer display technology, so you can stop optimizing.
We've been here before. Present performance means very little. What is relevant is the rate of change. It seems perfectly clear to me that the HTML/CSS/JS stack is improving much faster than Flash. Unless that rate of improvement significantly slows or Adobe significantly improve their rate of development, HTML/CSS/JS will inevitably overtake Flash fairly soon.
Given that we're in the middle of a browser war, I don't see how Adobe could possibly compete. In order to beat WebKit in the long term, they would need to out-spend and out-think the combined forces of Apple, Google, Nokia, KDE, RIM, Palm, Samsung and a small army of other developers.
I have to give credit to Adobe - Flash is fast, easy and generally works well. There's a hell of a lot wrong with it, mainly the lack of standards compliance and how little effort they've made on accessibility, but it is undoubtedly a good product. That's not really the question we're interested in though - the relevant question is what will be faster in a year or eighteen months. I will be absolutely astonished if Adobe isn't comprehensively beaten by the end of next year.
That isn't to say Flash is dead, there are a lot of avenues for Adobe to pursue and they still have huge momentum, but they're going to have to either up their game, specialise, or face the inevitable fate of any technology that doesn't iterate fast enough.
Looks like the improved version erases just the previous frame's ball, instead of clearing the whole canvas (just my best interpretation -- I'm not familiar with the canvas API).
EDIT: This link details what's going on here:
One important optimization rule to follow is to reuse as many pixels as possible between frames. What I mean by that is the fewer pixels that need to be processed each frame, the faster your program will run. A good example of this is when erasing pixels with the clearRect(x,y,w,h)method, it is very beneficial to clear and redraw only the pixels that have changed and not, for instance, a full screen 1920x1280 sized canvas. Unlike the Flash Player’s redraw regions, this management of "dirty rectangles" needs to be done manually for canvas. [http://www.kontain.com/fi/entries/94636/]
Apparently Flash Player optimizes the reuse of pixels automatically, and MobileSafari does not.
30 comments
[ 2.0 ms ] story [ 80.3 ms ] threadI was pleasantly surprised when I seen my HTC Desire running flash, but then after a few weeks it just got annoying and I turned it off, battery performance went up, and I have not once had an inclination to turn it back on.
There's a big difference between comparing a "good written" flash thing which you make yourself and having the flash enabled while browsing the web. With first you can demonstrate Flash's superiority, with the second you're picking up all the incompetent code written by anybody and almost 100% of it is used only to make something totally unimportant just moving to get an attention from you.
When we consider Flash as the content delivery mechanism and not the movement based attention taker we're left only with videos and games on the web. But both should be optimized for mobile. For video, transcoding is needed. For games, better writing them native.
That's why I intend to use Opera Mini as long as it works.
I have it on ondemand, and while I seldom enable it, when I do I appreciate that I have the option.
Hardware acceleration for 2D Canvas would be nice to have, but what would be even better is WebGL. That would blow Flash out of the water for sure. WebGL was recently enabled by default in Firefox 4 nightly builds so it's looking like a lock for the final release; hopefully Apple and Google follow suit.
As a simple ball bounce animation, i dont think hardware acceleration kicks in during this demo. With all the html5 love Apple is showcasing (apple/html5), they should have enabled hardware acceleration for html5 long before.
Speed Test: Flash vs HTML5 On The Nexus One [video]
http://news.ycombinator.com/item?id=1657853
If anything, I would think that Flash has the potential to be faster since it was designed from the beginning to do only what it does, whereas <canvas> is an extension to the already massively complicated technology blob that is HTML.
"--Call me an Apple Fanboy, fine. But there's a reason I've got work, how bout them Windows Developers?--"
Is he actually implying there is no work for Windows developers?
Everyone even relatively familiar with graphics rendering should involuntarily cringe when hearing comparisons like this.
See the light: http://www.mvps.org/directx/articles/fps_versus_frame_time.h...
Given that we're in the middle of a browser war, I don't see how Adobe could possibly compete. In order to beat WebKit in the long term, they would need to out-spend and out-think the combined forces of Apple, Google, Nokia, KDE, RIM, Palm, Samsung and a small army of other developers.
I have to give credit to Adobe - Flash is fast, easy and generally works well. There's a hell of a lot wrong with it, mainly the lack of standards compliance and how little effort they've made on accessibility, but it is undoubtedly a good product. That's not really the question we're interested in though - the relevant question is what will be faster in a year or eighteen months. I will be absolutely astonished if Adobe isn't comprehensively beaten by the end of next year.
That isn't to say Flash is dead, there are a lot of avenues for Adobe to pursue and they still have huge momentum, but they're going to have to either up their game, specialise, or face the inevitable fate of any technology that doesn't iterate fast enough.
Looks like the improved version erases just the previous frame's ball, instead of clearing the whole canvas (just my best interpretation -- I'm not familiar with the canvas API).
EDIT: This link details what's going on here:
One important optimization rule to follow is to reuse as many pixels as possible between frames. What I mean by that is the fewer pixels that need to be processed each frame, the faster your program will run. A good example of this is when erasing pixels with the clearRect(x,y,w,h)method, it is very beneficial to clear and redraw only the pixels that have changed and not, for instance, a full screen 1920x1280 sized canvas. Unlike the Flash Player’s redraw regions, this management of "dirty rectangles" needs to be done manually for canvas. [http://www.kontain.com/fi/entries/94636/]
Apparently Flash Player optimizes the reuse of pixels automatically, and MobileSafari does not.