mocap.js – A Motion Capture library

I've recently been playing around with the WebRTC (web real-time communication) stack, in particular getUserMedia which grants you access to the webcam and mic in javascript. In particular I've put together an alpha of a motion control library that allows the user to swipe their hand and have the webpage respond. More details can be found on the github page, but it makes more sense just to try the demo:

Demo - works in chrome and firefox nightly (at the time of writing)

The library is currently in its infancy but I'm planning to add auto-calibration and other niceties as time goes on. If it doesn't work for you, please let me know in the comments.

Filed under: Javascript No Comments

DeltaImg: resolution and bandwidth responsive images


A resolution and bandwidth responsive image system is shown. All img tags start pointing to the low res image versions, then javascript downloads (in the background) difference files to upgrade the low resolution images into a high resolution images, and as such doesn't waste http requests or any data... oh and there are some fun kitten demos as well. All files can be found at github.com/pci/deltaimg.


Responsive images are one of those current "cutting-edge" web topics - developers would like to do something but the specs don't (yet) allow it.

The basic idea is this - you want to serve agile small image to your mobile viewer, whilst serving crisp high-quality images to viewers with lots of pixels (think new iPad). Then there's also the bandwidth problem - users with a crummy connection would probably rather get a crummy, but usable, image that have to wait an age to see the whole page.

This is my attempt at helping with the problem.


My very own infinite carousel (aka – “picture-spinny-thing”)

After a conversation with a friend, I set about making a non-flash carousel because, you know, I'm cool and that..... Then after making it I needed to store it somewhere, so here it is! All-told about 2 hours work, with pictures stolen from my church's website, mainly because the graphics team there are simply amazing.

You might ask why not use flash, after all I'm not against flash. But in this case there are two main reasons why you might try a non-flash solution:
- So it can work on the iPhone/iPad
- Because screen readers (for the partially sighted/blind) can't read flash sections of a webpage but, conversely, any html present can clue the reader into what's going on semantically within a page.

Click the picture below to get to the demo:

Geek notes: the glow effect is CSS3 box-shadow (learn more here), IE6-8 support is added with CSS3Pie


Web Workers and drive by CPU nabbing

Web workers are a great part of the html5 specification. They let you run a javascript program in a separate process; so that complex tasks can be done in the background without blocking nice, fluffy, user interactions with the page. Better still, if multiple web workers are run and multiple CPUs are available then they get scheduled across all the processor - multi-core javascript enables whole new avenues of complex (and awesome) code to be written and deliver a great experience.

....you can probably sense the but coming.....but - this means any page you navigate to, any link you click, any random website with funny pictures of cats on, has unfettered access to your CPU. While you browse worldsfunniestcats.com, it could be using your electricity to generate BitCoins for itself, or crack passwords.

To prove a point, below is a page that spawns a few web workers and sets them, continuously, generating prime numbers. Open up the page in a modern browser and check out your task manager (closing the page kill the web workers):

Update: It doesn't max-out the CPU in Opera...why? Because apparently Opera is so fast that it can handle the workload without breaking a sweat!

Update 2: Apparently IE10 can hack it too, looks like firefox and chrome are trailing on this..... there's a sentence I never thought I'd write.....

Update 3: On further investigation, it looks like Opera's performance is a combination of running the script at great speed AND some kind of limits on web workers, either in terms of number or CPU usage. I can't comment on IE10's performance as I don't have a windows 7 laptop..... if anyone is listening at microsoft..... *hint* *hint* :)


Box2d.js and load times

I recently discovered box2djs by Ando Yasushi, a nice little physics simulation engine made to run in javascript, here's an example from the homepage:

box2d-js homepage

However, it being a port of a port, there are one or two little problems. The main one by far is the delivery of the library - in the flash version, modules are loaded lazily (i.e. as needed), however in javascript all the different libraries need loading up-front.... all 64 of them... in a set order... and each file has the full MIT license information at the top!

So the browser has to make 64 different server calls and pull down 349 Kb just to start doing anything. This can clearly be improved on.

Turning on server-side gzip, is a good way to reduce the amount of data transmitted with no real downsides. Also putting everything in one file will help a lot, but more can still be done.

To shrink the javascript filesize even more there are two paths: compressors or encoders. Compressors (like yahoo's YUI compressor) remove whitespace, rename internal variables to have shorter name and do a hundred and one different optimizations, but crucially, the end javascript is programmatically identical to the input file (a browser doesn't care if a variable is called "theGreenBallsRadius" or "aPb"). Encoders (like Dean Edwards' Packer) go one stage further - they encode the resulting file (much like gzipping) and then tag on some javascript so the browser can decode it at the other end, but this creates some javascript overhead before things can get up and running.

Now because everything is better in table form:

NameFilesSize (Kb)w/ GZip (Kb)

This shows near 85% improvement just by putting everything in one file and turning on gzip! But even better, the filesize can be halved on top of this.

My first instinct was to go with the Packer encoded version: it's the smallest (or close enough) whether the user's browser supports gzip or not. But the YUI compressed version is my recommendation. Why? Well I'm glad you asked! The vast majority of visitors' browsers will accept gzipped files, so for them there's no filesize difference between YUI and Packer. Now with YUI you can just un-gzip and you're away, however with Packer you unzip then decode then you're good to go. This additional step will still halt rendering until it's complete, making the page load feel slower - the exact thing we were trying to improve.

There you go, a good library made better! Now onto hacking it.....



I'll admit that I'm slightly obsessed with zoomooz.js, it's a cross-browser (excluding IE) nice zoom plugin for jQuery. And although it has some issues with scrolling it's a top-notch plugin in my books. To showcase it's greatness I made a mock-up of a picture gallery*:

*if any of the pictures are yours let me know and I'll acknowledge you here.

The polaroid effect is CSS based, with a bit of javascript to fit the pictures. The random distribution uses CSS3 transforms (random rotation with a slight translation). ZooMooz.js then does the rest!

Geek Bootnote: The page uses @font-face and html5 data attributes to keep track of the ordering, the juicy javascript can be found here (script.js)

Update: A good intro on Zoomooz.js can be found here.


Interactive Ray Optics

Here's the ray optics demonstration I made during my PhD. It models ray-surface interactions in javascript... and that's pretty much it! But it's still quite a fun way to waste 5 mins. Any modern browser should be able to run it*.

Ray Optics Demo* i.e. not IE