Pong written in both flash and HTML5. Left side is flash, right side is HTML5.(labs.codecomputerlove.com)
labs.codecomputerlove.com
Pong written in both flash and HTML5. Left side is flash, right side is HTML5.
http://labs.codecomputerlove.com/FlashVsHtml5/
128 comments
You have asked an important question: how do you detect the keyboard layout (in Javascript) when using KeyUp/KeyDown events? A regular press event will provide the charCode but the press/release versions do not.
There are no keys that will work for everyone. I use Colemak -- the A and Z keys are in the same spot as Qwerty, but K is where N is on Qwerty, so that's a difference. Throw in Dvorak, and you only have A and M in the same place on those three.
A "right" answer is to make the keys remappable.
A "right" answer is to make the keys remappable.
On my french keyboard, both sides are equally handicapped, because the M too isn't on the same line as on a US keyboard : utterly unplayable :)
I always install a us keyboard configuration as well in addition to my french keyboard for those kinds of issues. There is no need for two keyboard. Then you can just switch by pressing ctrl-shift simultaneously on windows.
Or just buy a US layout keyboard and use that! It's much better for coding anyway (especially for ObjC and its square brackts - these things aren't even labled on most international keyboards). Also it allows for much faster zergling production!
I quite like my Slovenian keyboard thank you very much. I have all the stuff I need to program (PHP mostly, so C would be cool to), and I have used English keyboards and didn't like them.
I'm sorry if I'm rude, but there are other characters than a-z (which I need to input quite frequently). And that is a concept English speaking developers seem rather hard to grasp (judging by most of the software out there). I just wanted to point that out.
I'm sorry if I'm rude, but there are other characters than a-z (which I need to input quite frequently). And that is a concept English speaking developers seem rather hard to grasp (judging by most of the software out there). I just wanted to point that out.
Interesting problem of tuning both sides speed. Here (small Atom netbook hooked to big screen) the ball moves noticeably faster on the Flash side. To the point of making me lose a Pong match with myself.
Firefox on windows 7 - both are smooth but html5 slightly more so.
1.6GHz MacBook Air (late 2010): After an initial stutter on the HTML5 side (where the ball was served), both sides perform equally to my eyes.
Core i7 920 on Chrome 9 (canary). Both sides are equally fast, but there's a visible stutter when the ball's moving quickly.
Oh man, Chrome shipped 8 versions already? They've achieved version-number-parity with IE! :)
Chrome has four different versions at any one time. Stable, beta, development, and canary. Canary is essentially a nightly build, and is buggier than a very buggy thing indeed, as you might reasonably expect.
No, stable is still version 7.
Pre-Atom Eee 900, Linux, Chrome 6, the Flash side is almost unplayably sluggish, while the HTML5 side zips along.
1005PE here (ie. also an Aton netbook). Flash side stutters for me, while HTML5 is smooth.
Perhaps you're better at controlling the {A,Z} keys with your left hand than you are at controlling {K,M} with your left?
The html5 side has a nice smooth movement for me. The flash is more jerky, and changes speed. This is on Chromium 9.
The Flash side was unexpectedly slow, and comments on this same article on Reddit indicate that it is because they are doing a lot of JavaScript-to-Flash communication, which is unusual for a game, as well as enabling "wmode=transparent", which allows DOM elements to be positioned on top of Flash content, slows down Flash content, and is apparently unnecessary for this page.
HTML5 does all of that out of the box without any flags, so it's a fair comparison.
Not when they are not needed, which is about 99% of the time. When I think "Flash", I think games, video and cool experiments with shining particles.
None of that requires those flags, so I think forcing those is not fair.
None of that requires those flags, so I think forcing those is not fair.
Flash defaults to "non-web-friendly" (windowed) flags by default, HTML5 defaults to "web-friendly" flags. As a commenter said, you can also make the canvas tag opaque by using a special browser-specific style.
If you remove the windowless flag from Flash, you would have to add the opaque flag to HTML5 to make it a fair comparison.
If you remove the windowless flag from Flash, you would have to add the opaque flag to HTML5 to make it a fair comparison.
Could you clarify this comment? I'm unsure what HTML5 does out of the box, and what flags you're referring to. Thanks!
HTML5 allows you to position elements on top of the drawing canvas and use a transparent canvas so the background of the page would show through the drawing. Flash does not, unless you add wmode=transparent to the parameters.
It just makes it a bit of a random comparison, if changing one unneeded setting changes who "wins".
You can set the moz-opaque boolean attribute on canvii in Firefox to disable it.
I was wondering why the ball appeared clipped on the flash side, even though I can't remember having seen this problem in a flash game before. It was also unusually slow. That old 3D first-per-view demo with textures had a clearer image and was faster.
I call it unfair.
I call it unfair.
This is depressing. It's 2010, and our computers have issues rendering Pong.
Granted, the ball is using more pixels to render itself than all the pixels available on an atari 2600, and it's going through 10 levels of abstraction layers rather than using assembly code to blit pixels directly to the framebuffer...
Framebuffer? There is no such thing in the 2600 (see "Atari_TIA" Wikipedia entry for details).
Call it what you like, but it's basically a line-based "framebuffer" in memory, and the display just happens to be reading from that memory every time it draws a line. IIRC you get something like 80 clock cycles to blit your pixels into that memory space before the next line gets drawn, but it's still acting as a framebuffer.
No, it is not even a line-based framebuffer. Starting on every H-Sync interrupt, the CPU has to change the TIA chip latches with accurate timming for "producing" pixel output. So, there is no framebuffer at all.
Ah, then perhaps I'm confusing it with another console that predates my existence :P
My computer (an iPhone) totally failed to render both sides of the game.
Only because we keep trying to reinvent it using an increasingly esoteric, inefficient (from hardware's POV, if not a human's), high-level, abstract method, using newborn tools rather than proven ones.
While I'm seeing better perf on the flash side (XP, FF 3.6.12), Pong isn't exactly an ideal test bed.
Interesting that on the page they say "We believe the two technologies are not in competition" but that is exactly what this type of demo is going to stir up. While the improvements in browsers and javascript engines as of late has been nice, I think we're still a few years off from real parity, especially on lower-spec'd machines. Make no mistake, Flash on the web will be obsoleted by HTML5. But not yet, especially for all those people who don't update their browser every month.
For the time being, if Flash evangelists really wanted to make a point, they should do this same type of set up, but with a complicated (hardware-accelerated?) visualization.
Interesting that on the page they say "We believe the two technologies are not in competition" but that is exactly what this type of demo is going to stir up. While the improvements in browsers and javascript engines as of late has been nice, I think we're still a few years off from real parity, especially on lower-spec'd machines. Make no mistake, Flash on the web will be obsoleted by HTML5. But not yet, especially for all those people who don't update their browser every month.
For the time being, if Flash evangelists really wanted to make a point, they should do this same type of set up, but with a complicated (hardware-accelerated?) visualization.
HTML5 will eventually achieve comparable functionality and more importantly, business models may emerge (flash gaming is an industry after all) given time that make it a viable alternative to the people making games. At some point it'll almost certainly coexist alongside Flash games on sites like Armor, Kongregate etc. But it's not going to kill Flash.
HTML5's real fight is against native mobile platforms where it's competing against much richer platforms than Flash and more importantly business models that revolve around a mountain of cold hard cash people throw like confetti at the games they like.
If all it does is coexist or even entertaining the fantasy where it 'kills' Flash its lost, Flash is just the tip of casual gaming. Solipskier made $70,000 in the first 2 months of their iOS version ... against $16,000 on the Flash version (and that's more than most Flash games make).
HTML5's real fight is against native mobile platforms where it's competing against much richer platforms than Flash and more importantly business models that revolve around a mountain of cold hard cash people throw like confetti at the games they like.
If all it does is coexist or even entertaining the fantasy where it 'kills' Flash its lost, Flash is just the tip of casual gaming. Solipskier made $70,000 in the first 2 months of their iOS version ... against $16,000 on the Flash version (and that's more than most Flash games make).
Firefox 3.6.12 on a Mac.
For what it's worth:
Interesting behavior on the left side, the ball occassionally sticks to the paddle and vibrates, travels up the paddle and then scores a point against itself. (This is not a set up for a punchline.) Also, both sides show some stuttering in the ball movement.
I wrote a simple pong game once for a CS class, and in my case a vibrating ball was caused by simply negating velocity on a collision rather than setting its sign. It's better to do something like this (using C pseudocode as that's my native language):
if(collision) {
switch(side_of_screen) {
case LEFT:
horiz_speed = abs(horiz_speed);
break;
case RIGHT:
horiz_speed = -abs(horiz_speed);
break;
case TOP: // Positive Y is downward
vert_speed = abs(vert_speed);
break;
case BOTTOM:
vert_speed = -abs(vert_speed);
break;
}
}Chrome 7.0.517.41 on a Mac. I got a score of 9135 (I stopped when it exceeded 9000).
http://img201.imageshack.us/img201/8486/screenshot20101102at...
Method: Get the ball to hit a paddle on the top or bottom. It seems the code that deals with paddle collisions only imagines horizontal collisions, so, every frame (or whatever unit of time it uses), it registers a collision and reverses its horizontal direction. This is the "sticks to the paddle, vibrates, and travels up the paddle" behavior you describe. Move the paddle up and down to follow the ball's vertical movement, so it doesn't fall off. You rack up a lot of collisions very quickly like this.
This works much better on the left side, for whatever reason. I've succeeded twice in getting the ball to vibrate on the paddle while moving slow enough vertically that I can follow it and prevent it falling off. I haven't managed to do it on the right side; I have gotten it to vibrate, but only for a short time before it gets flung away.
Also, sometimes the ball vibrates on the top or bottom surface for a little while (fraction of a second). This has happened only on the left side so far.
http://img201.imageshack.us/img201/8486/screenshot20101102at...
Method: Get the ball to hit a paddle on the top or bottom. It seems the code that deals with paddle collisions only imagines horizontal collisions, so, every frame (or whatever unit of time it uses), it registers a collision and reverses its horizontal direction. This is the "sticks to the paddle, vibrates, and travels up the paddle" behavior you describe. Move the paddle up and down to follow the ball's vertical movement, so it doesn't fall off. You rack up a lot of collisions very quickly like this.
This works much better on the left side, for whatever reason. I've succeeded twice in getting the ball to vibrate on the paddle while moving slow enough vertically that I can follow it and prevent it falling off. I haven't managed to do it on the right side; I have gotten it to vibrate, but only for a short time before it gets flung away.
Also, sometimes the ball vibrates on the top or bottom surface for a little while (fraction of a second). This has happened only on the left side so far.
Running Gentoo with Firefox 3.6.9 on a Core i7, HTML 5 is much more noticeably laggy while Flash (10.2.161.23) is perfectly smooth. In Chrome they're more or less equivalent. (Firefox's sluggishness could have something to do with many Firefox addons and having over 100 tabs open.)
Where exactly are you getting Flash Player 10.2.161.23? Pretty sure latest release is 10.1.x.
From Gentoo's ebuild:
MY_64B_URI="http://download.macromedia.com/pub/labs/flashplayer10/flashp...
and hence:
http://download.macromedia.com/pub/labs/flashplayer10/flashp...
Edit: I do know that "Square" isn't an official release, it's a preview, but boy is it great. 64-bit support on Linux, hooray! 32-bit with nspluginwrapper is a pile of crap and would consistently crash, also taking out Firefox before they abstracted out the plugins from the browser. Secondly given Flash Player is insecure by default, it's probably better to be using the bleeding edge release over the current stable since it's less likely to be targeted.
MY_64B_URI="http://download.macromedia.com/pub/labs/flashplayer10/flashp...
and hence:
http://download.macromedia.com/pub/labs/flashplayer10/flashp...
Edit: I do know that "Square" isn't an official release, it's a preview, but boy is it great. 64-bit support on Linux, hooray! 32-bit with nspluginwrapper is a pile of crap and would consistently crash, also taking out Firefox before they abstracted out the plugins from the browser. Secondly given Flash Player is insecure by default, it's probably better to be using the bleeding edge release over the current stable since it's less likely to be targeted.
are you sure its the flash that is smooth? I got have the same firefox on osx, and flash is laggy compared to the smooth js version. Flash is left, remember?
MacOSX on a 2.16GHz Dual2Core Macbook with Chrome:
HTML5 is really fluent here while Flash seems somehow laggy (I would guess 20 FPS or less).
I think I also found a bug in the Flash version. The ball got stuck somehow at the top bar.
I think I also found a bug in the Flash version. The ball got stuck somehow at the top bar.
Same experience here. Cool concept, wonder how it matches up to silverlight?
In contrast to other commenters, the html5 side runs super-smooth and the flash is noticeably jerky.
I'm running a 2008 iMac.
I'm running a 2008 iMac.
In contrast? Everyone has said the flash is not smooth and html5 is.
Not everyone.
Plus who knows how each side was coded. I make games for a living and more times than not, jerkiness/glitches are an indication of bad programming than the platform it was written in. Pong is an ultra-simple game but you'd be surprised even on a game as basic as that the issues that can crop up that require elegant coding. Collision in particular -- the simplest, most obvious way in pong to check when the ball collides is to check the intersection of a point and a line, or a point and polygon/rectangle, the point being the edge of the ball (top/bottom of it for the walls, left/right of it for the paddles) versus the edge of the paddle or the whole paddle. More precise, but more math used and thus a less common way of writing the game, is to check the intersection of a circle and a line segment/polygon.
For example in flash, there are some built-in methods that everyone tends to use but don't get "pixel perfect collision" -- if you google that phrase you can see where people have tried to come up with perfect collision and how complicated all the math is for it.
I know for a fact just from playing this flash/html5 pong that it wasn't coded perfectly because it glitches when the ball gets to too high of a speed, either getting stuck in the wall and bouncing along it but not away from it, or going right through the paddle.
So this is really apples and oranges, unless both halves were coded with the exact same algorithms for everything (and just different syntax for the languages) -- very unlikely -- and, as evidenced by the other commenters also completely dependent on the environment/browser implementations of html5 and the flash plugins.
However, way cool on the link-bait worthiness :) I shoulda thought of this =P
Plus who knows how each side was coded. I make games for a living and more times than not, jerkiness/glitches are an indication of bad programming than the platform it was written in. Pong is an ultra-simple game but you'd be surprised even on a game as basic as that the issues that can crop up that require elegant coding. Collision in particular -- the simplest, most obvious way in pong to check when the ball collides is to check the intersection of a point and a line, or a point and polygon/rectangle, the point being the edge of the ball (top/bottom of it for the walls, left/right of it for the paddles) versus the edge of the paddle or the whole paddle. More precise, but more math used and thus a less common way of writing the game, is to check the intersection of a circle and a line segment/polygon.
For example in flash, there are some built-in methods that everyone tends to use but don't get "pixel perfect collision" -- if you google that phrase you can see where people have tried to come up with perfect collision and how complicated all the math is for it.
I know for a fact just from playing this flash/html5 pong that it wasn't coded perfectly because it glitches when the ball gets to too high of a speed, either getting stuck in the wall and bouncing along it but not away from it, or going right through the paddle.
So this is really apples and oranges, unless both halves were coded with the exact same algorithms for everything (and just different syntax for the languages) -- very unlikely -- and, as evidenced by the other commenters also completely dependent on the environment/browser implementations of html5 and the flash plugins.
However, way cool on the link-bait worthiness :) I shoulda thought of this =P
At the time of writing the comments seemed to be leaning towards flash performing better.
Everyone on a Mac has said that.
On my Motorola Droid running Froyo, the flash side is much smoother. On the JS side I couldnt really control it because the browser was also intercepting every keystroke and trying to put them in the url/search bar.
Interesting. A big complaint leveled against Flash was that it steals keyboard focus. This causes problems when you're playing a Flash game and then want to tab away from the screen. In this instance, that it doesn't delegate control to the browser is a feature.
Also on a motorola droid here. I experienced the same problem, but if i tapped on the flash side first before giving keyboard input, the browser would stop intercepting my keyboard stokes, and I could control the javascript side.
I also noticed the flash side was smoother, while the javascript side was very jerky.
I also noticed the flash side was smoother, while the javascript side was very jerky.
Really cool. On my system the flash is way faster than the HTML5
It looks like a non-standard key mapping, like dvorak, causes schizophrenic confusion.
Windows 7 x64, Chrome, Flash is jerky, glitchy and ugly, HTML5 is smooth and nice.
People keep saying things like this. Seriously: If a flash pong game is messed up, it's the programmer's fault.
I would definitely like to see the source for this. Over time, it's become a lot more clear to me that Flash's defaults (and the normal tutorial code you read) are tuned for high resolution advertising contexts, mostly, so the need for taking steps to get good real-time / interactive performance out of Flash isn't always totally obvious to people.
Safari 5 on OS X: HTML5 smooth, Flash sluggish. (Does the "known performance issue" on Safari 5 affect the Flash side?)
Anyway, as the author suggests, this kind of test has merely entertainment value. While 95% of Flash could be replaced by HTML5, Flash still has its place on Games.
Anyway, as the author suggests, this kind of test has merely entertainment value. While 95% of Flash could be replaced by HTML5, Flash still has its place on Games.
Make sure you've excluded the URL from Vimium/Vimperator before playing!
I've sought high and low for a way to do this on Vimperator, but I can't for the life of me figure it out. Forgive me for asking, but how do you exclude urls in it?
Check out the Automatic Commands section under help. Here's an example from that page.
Enable passthrough mode on all Google sites:
:autocmd LocationChange .* js modes.passAllKeys = /google\.com/.test(buffer.URL)
Actually you don't need to do so - at least in Vimperator you can enter 'pass through mode' by pressing ctrl-z. This disables vimperator keys and allows you to interact with sites in 'normal way'.
On Vimium I just hit 'i' to go into insert mode.
Heh, just noticed that myself.
Why is this?
I assume because these plugins use unshifted letter keys to control browsing, but pong wants to see these keys.
Both sides seem about the same to me but I also have the Flash 64-bit player for OS X http://labs.adobe.com/downloads/flashplayer10.html.
For those interested in Flash game optimization here's a video on porting Plants vs Zombies to Flash http://tv.adobe.com/watch/max-2010-develop/building-plants-v... (that would be and interesting split screen!).
For those interested in Flash game optimization here's a video on porting Plants vs Zombies to Flash http://tv.adobe.com/watch/max-2010-develop/building-plants-v... (that would be and interesting split screen!).
When I use my iPhone to play this game HTML5 side always wins!
I didn't notice any real difference between the two on Firefox 3.6.
The only complaint I had was that there was some sort of hit detection problem on the HTML5 side (the ball got caught inside the paddle, and the rally count shot up by about 30 in about a second). I can't hold it against the HTML5 code though, since the flash side did it to me too about 10 seconds later.
The only complaint I had was that there was some sort of hit detection problem on the HTML5 side (the ball got caught inside the paddle, and the rally count shot up by about 30 in about a second). I can't hold it against the HTML5 code though, since the flash side did it to me too about 10 seconds later.
Besides a few glitches in the html5 side it looks pretty much the same. I would love to see the FPS count though
Can't tell the difference on a MacMini2,1 w/ Safari 5.latest – both sides jerk a bit sometimes, but are mostly smooth-looking. Maybe if I blew it up to full-screen it would show a noticeable difference.
Reminded me of a BeOS demo, where windows would send each other messages about own position and the ball's physics.
Reminded me of a BeOS demo, where windows would send each other messages about own position and the ball's physics.
My experience (Chrome on Linux) was smooth in both technologies (apart from a collision detection bug on the canvas side). Really neat demo though - when they're synced, it's weird to be aware that there's a sort of slight of hand happening with the ball as it crosses the center line.
I love how the score is persisted between visits if you close the tab or navigate back to the page later.
I am pretty sure that the Flash side could be better. I've seen lots of flash games that run smoothly.
It's interesting that the Flash version has a frame rate of 100 and a calculated size of 8000 by 9000 pixels, while the javascript version leaves these undefined. I have no idea what the performance implications these attributes have, as I have never seen either so high.
this should use a constant FPS game loop (http://dewitters.koonsolo.com/gameloop.html). Currently, the flash side is much faster; supposedly due to it rendering faster in my browser.
wouldn't that defeat the purpose?
I guess it would if the idea is to show one has superior performance over the other. I was just commenting from the perspective of having a more uniform experience on both sides.
I'd love to see the Flash source. It flags for me, but I don't think it should have to.
Interesting, at first the HTML5 was notably faster and smoother than the flash version, then the HTML5 became slightly sluggish and the flash version became smooth and fast. Anyone else get this? I'm on Chrome.
Very cool, but HTML5 side barely working at all for me in Chrome on OS X.
Three generations old MBP with Chrome 7, everything is okay, both sides seem to be equally smooth.
HTML5 way smoother for me with Chrome unstable on Ubuntu.
Looks like my left cerebellum and my right hand is winning, not sure if it's because of HTML5 or not. Flash is using less CPU, Ubuntu 10.10 64bit with Chrome 8.0.552.23 and Flash 10.2 d161.
Both ran smoothly (FF 3.6.12), but there were some collision issues with HTML5. Hitting the ball with the side of the paddle almost always results in the ball passing through it.
Ubuntu and chrome on older laptop, flash runs noticeably faster, and has odd accelerating effects on flash side. So, Flash is faster but not a consistent speed?
On my system here at work(Dell Core2Duo Xeon, 8GB win7x64), the "HTML5" side was slightly less glitchy, and the flash sides graphics were more antialiased...
At one point the ball was going so fast I couldn't see it.
While playing with myself... ahem... I noticed the html side being a little laggy with key presses. Any speculation as to why? Freaking awesome work!
Entirely unplayable on the flash side due to slowness and worked beautifully in HTMl5.
Dell Mini 9 running Crunch Bang 9.10 (Ubuntu respin) with Opera 10.60.
Dell Mini 9 running Crunch Bang 9.10 (Ubuntu respin) with Opera 10.60.
Running on Firefox 3.6 on a Mac, both sides were very similar speeds. Didn't really see a change at all. Good concept and great execution.
MacBook Pro 15" with Firefox 3.6, but I noticed jerkiness on Flash, HTML was definitely smoother
I'm running Safari 5 on an older Macbook, and the Flash side is noticeably faster/smoother. That must be the 'known issue...?'
[deleted]
I had to refresh the page a couple of times for it to work. Using chrome on Ubuntu 10.10 x64.
[deleted]
Mac OS X, Google Chrome, all up to date stuff. Both run exactly the same.
awesome! flash ball speed is slower by the way... and keeps losing :)
my setup: firefox 3.6.12 and chromium 6.0.472.62, 64bit linux
flash (left) is faster/smoother than html5 (right), so much that right could never win.
flash (left) is faster/smoother than html5 (right), so much that right could never win.
Where's the touch screen version?
I only see the right side.
IBM thinkpad T61, 2GB ram, running firefox 3.6.8 for Ubuntu 9.10 (yeah yeah, I know), and Flash 10,1,82,76 .
Ball is nice and smooth on HTML5 side, and kind of jerky on flash side. That could just be Linux+flash issues, but the animation for HTML5 is super-smooth, so I'm guessing it's just bad flash plugin.
Ball is nice and smooth on HTML5 side, and kind of jerky on flash side. That could just be Linux+flash issues, but the animation for HTML5 is super-smooth, so I'm guessing it's just bad flash plugin.
Flash on linux sucks quite a bit unfortunately :(
Yeah in the old days it performed quite bad. Nowadays with the newer distro's like suse 11, (k)ubuntu and a couple of others I really havent found any more glitches than on any regular windows machine running flash..
I develop with flash regularly on my Linux machine (Ubuntu 10.something), and it's definitely a bear compared to windows. I'll be happy for the day I can walk away from flash, but it makes computationally intensive consumer applications much easier/feasible. When we started out project almost three years ago, it was such a clear winner over JS, but now it's becoming a wash.
I code Flash too, on 2.26 Ghz laptop running 4gb and multiple distro's, no real problems here..
A lot of us Flash coders actually want to drop Flash from our websites, widgets and resumes. It performs bad and puts a lot of stress on the CPU, blocking my vital programs from running.
I also dont like Flash because Flex Builder is not a free tool and because of all the security issues in Flash that Adobe just never seems to get fixed. http://www.adobe.com/support/security/bulletins/apsb07-20.ht....
Potentially leaving my computer including webcam feed and microphone wide open to anyone having an exploit before I update. http://blog.guya.net/2008/10/07/malicious-camera-spying-usin....
However, I think Flash (or read Actionscript 3.0) is a necessary evil to be able to do what you want to do.. fast and to a mass audience, see this table for statistics http://www.adobe.com/products/player_census/flashplayer/vers....
I've been coding Actionscript for some time now, but only started really liking it when 3.0 came out. I remember when the Papervision project became popular I loved coding Actionscript.... I still do and I dont think JS has the right properties to become anything close to Flash.
Adobe really is on the right way by including hardware accelerated graphics. http://www.tgdaily.com/software-features/38273-adobe-flash-p....
I hope they improve upon this a bit though..
A lot of us Flash coders actually want to drop Flash from our websites, widgets and resumes. It performs bad and puts a lot of stress on the CPU, blocking my vital programs from running.
I also dont like Flash because Flex Builder is not a free tool and because of all the security issues in Flash that Adobe just never seems to get fixed. http://www.adobe.com/support/security/bulletins/apsb07-20.ht....
Potentially leaving my computer including webcam feed and microphone wide open to anyone having an exploit before I update. http://blog.guya.net/2008/10/07/malicious-camera-spying-usin....
However, I think Flash (or read Actionscript 3.0) is a necessary evil to be able to do what you want to do.. fast and to a mass audience, see this table for statistics http://www.adobe.com/products/player_census/flashplayer/vers....
I've been coding Actionscript for some time now, but only started really liking it when 3.0 came out. I remember when the Papervision project became popular I loved coding Actionscript.... I still do and I dont think JS has the right properties to become anything close to Flash.
Adobe really is on the right way by including hardware accelerated graphics. http://www.tgdaily.com/software-features/38273-adobe-flash-p....
I hope they improve upon this a bit though..
64-bit Linux is even worse, as it has to go through a 32-bit adapter to work in 64-bit Firefox. Video is unwatchable for me on a Core i7 with a fast video card.
Yeah, I use a 32 bit compiled version of firefox called swiftfox for all my flash debugging/testing. Definitely slow as heck, but, faster than using the wrapper/adapter method.
[deleted]
Same here, Chrome 7 on OS X.
windows 7 and chrome with the same results. there is noticeable jerkiness as well as the ball flickering
CPU was pegged. I'll blame the flash side.
Awesome demo tho. Would love to see source of the flash part (maybe I missed it) so we could compare the source, not just performance (which seems to be about the same on my 5 year old laptop).
edit: who's now working on a (HTML5|Flash) vs Silverlight demo? That would be even more awesome.