Friday, April 10th, 2009

Metatunnel 1k Demo: JS vs. OS

Category: Canvas, Fun

Dion and I talk frequently about how the web platform’s capabilities are approaching the desktop, which features like canvas and faster JavaScript run-times. It’s great to get a piece of humble pie like this one.

FRequency created an interesting demo (as in “demo scene”) of a “metatunnel”:

Paulo Falcão ported this to JavaScript using <canvas>; how well does the JS version perform, you ask?

You get about 5 FPS at that size on Google Chrome, Safari 4 and Firefox 3.5 pre-releases; much worse on earlier browsers of course.

We’ve got a ways to go. ;-)

Posted by Ben Galbraith at 7:00 am

2.6 rating from 20 votes


Comments feed TrackBack URI

Speed would be less of an issue if better code was written for this purpose:
use sin, cos, sqrt lookup tables
Use a hidden canvas to draw the scene with, and set the visible canvas globalCompositeOperation = “copy”,
For Firefox add moz-opaque to the canvas tags
In the draw() routine remove the non repeating calculations, such as
Use a proper setTimeout call and don’t pass a string.
There is probably more but I’m a bit jaded at the moment…

Comment by TNO — April 10, 2009

Comparing the Ajax and Desktop versions is really more of a joke. The desktop version is written in assembler and passes a shader directly to an OpenGL card. The real test would be to see how well canvas 3D handles it…

Comment by Ben Galbraith — April 10, 2009

Well, i made this just for fun, and did not optimize the code much further, it was almost a direct conversion from my pure C multithread version (without GPU/GLSL) , by the way thanks TNO for your tips in javascript… :). It’s very interesting to compare the behavior of different browsers, my version of firefox (3.0.8) was slower and almost blocked the other tabs, chrome ( on the other hand was faster and the others tabs continue to work perfectly.
Using Canvas3d is a very nice idea, although it will only work on few browsers, and is necessary to have a GPU that runs GLSL. But will probably be very fast, i belive the speed will be similar to the original version, because like the original, the core part of the work will be done on the gpu using GLSL.

Comment by PauloFalcao — April 10, 2009

PauloFalcao, chrome is multi thread, if you have a blocking JS in a tab, others will always work without problems

Comment by WebReflection — April 10, 2009

WebReflection, Chrome is more than a multi thread a browser, is multi-process browser :)

Comment by PauloFalcao — April 10, 2009

It is true that the web is approaching the Desktop that is why people like me have made full online Desktops.

I still agree with Douglas Crockford when he said “the web is the most hostile software engineering environment imaginable” partly because their is no unified JavaScript package management system and now YUI 3.0 is implementing their own. What this means is using YUI, Dojo, and other major non-obtrusive frameworks together is not a good idea. Also, the prototype-obtrusive ones like Prototype and MooTools clearly cannot coexist.

Comment by jhuni — April 10, 2009

Paulo, I’ve uploaded a version with minimal optimizations (eliminating unused variables, initialize only once, switch to putImageData for drawing) and I’m already seeing a speed increase by a factor of 5 or so:

Would be interesting to see how much speed we could get out of it if we really started optimizing :)

Comment by hansschmucker — April 10, 2009

Still takes about half a minute to render a 1280×1280 image (resized to 640×640 to simulate antialiasing), but at least it looks nice :)

Comment by hansschmucker — April 10, 2009

Wow! Very, very nice optimizations hasschmucker! :) But all the speed you gain was lost because you changed sqr() to Math.pow which is a lot slower LOL :P
After changing your code to use the custom sqr instead of Math.pow, all the browsers run the demo about 100% faster, but with firefox 3.1b3 the speed increase was fantastic! From 5 FPS to 17 FPS :P
One way to speed up more is rendering 1 line per thread, with two cores speed would be about 2x faster, with 4 cores 4x faster, etc is possible to use threads, or something like threads in javascript?

Comment by PauloFalcao — April 10, 2009

Oops, didn’t think the overhead would be so high for Math.pow… I’ve replaced it with a*a again. I was still seeing a really significant speed update before, maybe because I’m on a later FF build than you.

About threads: There are so called worker threads. They have some severe limitations (most importantly, they can not share any data with the page and have to communicate via string messages), but they’d probably still give multicore systems quite a boost.

Comment by hansschmucker — April 11, 2009

Neat demo! Some more quick optimizations, mostly inlining to save function calls and reusing calculated values (it’s not very pretty), almost running real time on my crappy pc now (FF3.1 and Chrome). Also, use Q and W keys to adjust quality.

Comment by jseidelin — April 11, 2009

Thank you! God, we really need an SVN for these spontaneous collaborations.

Comment by hansschmucker — April 11, 2009

Both is fine with me… I’m just used to SVN. Question: Can Gist show the current version directly or do you have to checkout first?

Comment by hansschmucker — April 11, 2009

Here a quick port to Actionscript:

Comment by sev — April 13, 2009

Wow! I was on vacations, and so many stuff happened :) jseidelin very nice optimizations! sev, your Actionscript is very interesting, using Actionscript for rendering was definitely something to try, also a nice stuff to do if flash is to use a Pixel Bender Kernel Program to do the rendering, in flash 10 it will also run in software but it will use a especial compiler for it.

Comment by PauloFalcao — April 14, 2009

Leave a comment

You must be logged in to post a comment.