LeichtgewichtLeichtgewicht

2009/07/01 – 10:09

Pushing JavaScript particles

Yesterdays launch of Firefox 3.5 included some interesting new features which I really wanted to try out. Worker threads and Pixel manipulation support took my special interest.
Technically its comparable to Pixel Bender and the BitmapData API from Adobe Flash.
Both offer at least two threads and a image manipulation api to draw 3D. This means that any kind of image is possible in the browser (of course with varying performance).

To proof that for myself I tried to see how fast it would perform and started to port Ralph Hauwert’s Strange Attractor from AS3 & PixelBender to JavaScript. It took some time for me to get into 3D after some years of absence, but it worked out.

At first I tried to just implement it without the worker threads. If you take care to not do any unnecessary calculation (like with nice while(--i>-1) loops) the code worked out pretty soon at a reasonable speed. 50000 particles work on my 3 year old notebook at a acceptable framerate:


Note: Its actually at least 6 times slower than the flash+alchemy version. This example uses 50k particles where the original takes ~300k

After that I tried to add worker threads but thats where the fun stopped. They show the same problem as Ralph had with Pixel Bender. The pass-through of a large amount of data costs a lot of time (the values have to be copied). Since I had to use a huge array for both the transport and the calculation, the workers became amazingly slow. So I gave up on threads for this night.

Any suggestions or follow ups to make that code faster are very appreciated.

By the way: Google’s chrome is faster than the new Firefox

At the bottom line: Flash is still a lot faster than JavaScript, even on latest browsers(at least 6x but more likely around 15x concidering the framerate). Yet still there are some points that makes me think: There are no typed values in JavaScript. All values are 32bit floating point values. There have to be rounding operations and alike. There are no Vectors in use here or ByteArrays which handle all those operations at c level by themself. The image doesn’t have a method to clear which means it has to be constructed and descructed for every frame. Lack of typing doesn’t make LinkedLists recognizably faster and all that small details… Hmm… I wonder how fast JavaScript could be with a few changes.

Edit: Added the note about the performance comparison.

Tags: , ,

Comments

  1. V1

    Worker Threads would indeed be a way to go, and a memorizing function. Also apply common JavaScript speed ups and it could become faster.

    [] instead of new Array etc.

  2. Martin Heidegger

    “new Array” is only used at one time for the two main arrays, they are of course not always recreated (no effective processing time spent). Nevertheless I do create (with []) two 4×4 arrays for the mouse calculation (to make my code simpler) but they shouldn’t really affect a lot. I will think of a efficient way to remove them.

    Worker Threads slowed it down massively (as mentioned) which is assumingly because of the memory that has to be synchronized in order to bring the picture back on the screen.

    Having no iPhone I wonder if it works on the latest version, anybody tried it yet?

  3. rdza

    Not working on iphone OS 3.0; the initial picture & text are shown but no animation happens, also no errors reported by the embedded debug console.

  4. Martin Heidegger

    Thanks for mentioning. I could try it on a iPhone and its obviously just way to slow to see the reaction (somewhere around 0.2 fps). Not much to do about that.

Leave a Reply

Twitter Users!
Enter your personal information in the form or sign in with your Twitter account by clicking the button below.

Site informations

Martin Heidegger – Web Developerskype:mastakanedaxing:martin.heideggertwitter:leichtgewicht