VideoScript is an attempt to produce a completely plugin free solution for video playback for web browsers. Whilst Flash has largely been responsible for helping to revolutionise the way we use the Internet (and more specifically, browse the web) I feel that browser developers are pushing the performance of Javascript to a degree where the language combined with elements like CANVAS could provide a serious alternative.
Flash video, in particular, has never been praised for its high CPU usage during playback and despite the ideals of the developer, is not as portable as many think. I've personally seen 800x600 flash video playback take over 90% usage of my laptop's 2GHz dual-core AMD64 processor running under Linux - as a comparitor a native application played back 1280x720 video taking less than 70% usage at 800MHz.
I see no reason why Flash should use the extra power but - armed with my current knowledge of lossy image compression I just might be able to produce that viable alternative. I'll also be posting performance data for playback using some of the latest browsers including Safari, Chrome and of course, Firefox.
So, what advantages and disadvantages would this approach have as opposed to more traditional methods using plugins like Flash?
I'm going to start experimenting with the <CANVAS> element to see what sort of performance I can achieve by writing pixels directly to it.
Unless your browser doesn't support the <CANVAS> element, you should see a box gradually turning from black to red in colour. Sadly the performance on my linux box is abysmal so for the time being I'm going to leave this project well alone. The animation above is actually working on 4x4 pixel blocks not single pixels and should end within 1 second - manually timed, my laptop completed the animation in around 3 seconds and uses around 45% CPU at 2GHz at its peak. Ugh.
Having looked at some of the examples on MDC's Canvas page it's not an issue of fill-rate but seems to be down to delays in passing the drawing operations - lots of them seem to throw a wrench into the works. It's a well know fact that method calls generate a considerable amount of overhead and in Javascript this overhead is truly significant. I'm going to time the animation under Windows using Firefox, Chrome and Safari to see if they fare any better.
Update:Ok, I've added a mechanism that gets the current frame of animation after a second has passed. I refreshed the page five times on Linux and achieved an average of 14fps. Running under Windows things are a bit more promising - Firefox scores lowest at 18.5fps, followed by Safari and Chrome which achieve between 22fps and 23fps consistenly. Obviously this is a moot point as none of the browsers were able to achieve 25fps at an effective resolution of 80x60 which is tiny.
As I stated earlier this project is on hold until the browser manufacturers resolve to improve the speed of their Javascript engines (or the underlying code that handles drawing to the canvas. I figure that might take a while as my drawing routine would need at least a x4 fold speed increase to achieve 320x240 animation and x16 to achieve 640x480 animation - for 1280x720 HD that'd be a x48 then :D
In order to achieve these levels of performance it's neceassary for Javascript engines to incorporate run-time compilation rather than relying on interpreting the code - it's whether or not the browser manufacturers want to go to the trouble of doing just that that matters.
Another way around would be to allow developers to directly access the pixel data of the canvas and hence avoid the requirement for method calls at all. Writing directly to memory if much, much quicker but I'm guessing Mozilla/Apple don't want people to have the option as it might present a security risk.