Grab the Sencha Touch 2.0 Dev Preview here: http://www.sencha.com/blog/sencha-touch-2-developer-preview/

While I was able to get a basic app up and running quickly, unfortunately I spent a lot of time re-factoring into a proper MVC structure. The documentation on how to do this in Touch 2.0 is not there yet and there are some albeit small but killer differences between Touch1.0 and 2.0. To a novice like me they cost me a few hours.

Everything here was based off the Sencha ExtJS 4.0 walkthrough available here:

• http://www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-1/
• http://www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-2/
• http://www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-3/

The sample code is available on Github and you can go here and download the entire project in a single ZIP/TAR: https://github.com/FrancisShanahan/SenchaTouch2MVCHelloworld

Or you can fork the repo using git: http://help.github.com/fork-a-repo/

Here are a few key points:

a) Let the app instantiate your controllers and any global stores your app needs. Notice how the initial layout is created using xtypes? These are created as aliases in the views.

b) Let your controllers instantiate your views and stores.

c) Use Component Queries instead of Ext.getCmp(‘id goes here’). This’ll keep your code more manageable as the code base grows. Note, the “ref” name here is important as it’s used to generate getters for the view instances. E.g. a ref of “stationList” will create a getter on the controller of “getStationList”.

I’ve already heard from a few folks so it looks like this project is helpful. It’s also ready for dropping into a Phonegap shell. Fork it and update or let me know if there’s anything you’d like to see added.

Attribution: Today’s photo comes from Anxo Resúa’s stream on Flickr http://www.flickr.com/photos/anxoresua/4652943076/

HTML5 had originally laid out support for a new element (the “device” element) but it appears this element has been scrapped now in favour of the “getUserMedia” API. So far I have only seen the Opera Mobile Experimental build support this but hopefully it’ll get into Dolphin and other mobile browsers soon.

http://my.opera.com/core/blog/2011/03/23/webcam-orientation-preview

If you just want to cut to the chase here’s a video of the final result:

There are three moving parts here

• a) The client page which captures the video
• b) the server which is a simple Node broadcast server
• c) and the Client which is just a web page that renders the output.

The client is just a copy-paste from Opera’s website. I take the video stream, render it to a canvas, then grab the canvas as a base64 encoded image. One image per frame. I could not find a way to limit the video’s size so the resulting image is fairly large (240×400 on an HTC Incredible). I down-sampled, cutting the image data to reduce the traffic over the wire. Framerates are still pretty poor but this is just an experiment.

The server is a generic websockets server and gets a message which is a raw data/base64 stream. It broadcasts this down the any connected clients.

The client then is the simplest of all, just connects to the socket server and renders whatever it gets to an tag.

It’s all Javascript.

Client (this is a jade view).

h1
    Remote Webcam using NodeJS, Opera, Web Sockets and HTML5/Canvas
video(autoplay=true,id="sourcevid")
canvas(id="output")
div(id="log")
script
    var log = function(msg) {
       document.getElementById('log').innerHTML = document.getElementById('log').innerHTML + msg + "<br/>";
    };
    var video = document.getElementsByTagName('video')[0],
        heading = document.getElementsByTagName('h1')[0];
    if(navigator.getUserMedia) {
        navigator.getUserMedia('video', successCallback, errorCallback);

        function successCallback( stream ) {
            video.src = stream;
        };

        function errorCallback( error ) {
            heading.textContent = "An error occurred: [CODE " + error.code + "]";
        };
    } else {
        heading.textContent = "Native web camera streaming is not supported in this browser!";
    };

    var back = document.createElement('canvas');
    var backcontext = back.getContext('2d');

    var ws;

    if('WebSocket' in window){
        connect('ws://192.168.2.100:8080/');
    } else {
        log ('web sockets not supported');
     }

    function connect(host) {
        ws = new WebSocket(host);
        ws.onopen = function () {
            log('connected');
        };

        ws.onclose = function () {
            log('socket closed');
        };

        ws.onerror = function (evt) {
            log('<span style="color: red;">ERROR:</span> ' + evt.data);
        };
    };

    function send(msg){
        if (ws != null) {
            if(ws.readyState === 1) {
               ws.send(msg);
            }
        } else {
            //log ('not ready yet');
        }
    }    

    cw = 120;//240;//video.clientWidth;
    ch = 200;//400;//video.clientHeight;
    log('width = ' + ch);
    back.width = cw;
    back.height = ch;
    draw(video, backcontext, cw, ch);

    function draw(v, bc, w, h) {

        // First, draw it into the backing canvas
        bc.drawImage(v, 0, 0, w, h);

        // Grab the pixel data from the backing canvas
        var stringData=back.toDataURL();

        // send it on the wire
        send(stringData);

        // Start over! 10 frames a second = 100milliseconds
        setTimeout(function(){ draw(v, bc, w, h); });
    }

The server. Simple Broadcast app.

var sys = require("sys"),
    ws = require("./ws.js");

var clients = [];

ws.createServer(
	function (websocket) {

		clients.push(websocket);

		websocket.addListener("connect", function (resource) {
			// emitted after handshake
			sys.debug("connect: " + resource);
		}).addListener("data", function (data) {

		// handle incoming data
		// send data to ALL clients whenever ANY client send up data
		for (var i = 0 ; i < clients.length ; i ++ ) {
			clients[i].write(data);
		}

    }).addListener("close", function () {

		// emitted when server or client closes connection
		sys.debug("close");
    });
  }).listen(8080);

  sys.debug("Listening on port 8080");

The client.

<img src="" id="frame" style="width:240px;height:400px"/>

<div id="log"></div>

<script type="text/javascript">

	var img; 

	function Init() {

		img = document.getElementById("frame");	

	}

	$(document).ready(function () {

		Init();

	});

// Web socket connection stuff is next...	

	if('WebSocket' in window){

		connect('ws://localhost:8080/');		

	} else {

		log ('web sockets not supported');

	}

	var ws;

	function connect(host) {

		ws = new WebSocket(host);

		ws.onopen = function () {

			log('connected');

		};

		ws.onmessage = function (evt) {  	

            if (evt.data != null) {		

			  if ((evt.data[0]=== "d") &amp;amp;amp;amp;&amp;amp;amp;amp; (evt.data[1]==="a") ) img.src=evt.data;	//log('got' + evt.data);

			}

		};

		ws.onclose = function () {

			log('socket closed');

		};

		ws.onerror = function (evt) { 

			log('<span style="color: red;">ERROR:</span> ' + evt.data); 

		};

	};

	function log(msg){

		document.getElementById('log').innerHTML = msg + "<br/>" + document.getElementById('log').innerHTML ;

	}
</script>

Instead of broadcasting, you could store these frames in a MongoDB for assembly later. This would make the ultimate, storage independent video camera. Never run out of storage again!

I really need to start storing these snippets on github…

P.S. Everyone knows insects are clockwork which is why god made so many of them. Today’s image is from http://www.insectlabstudio.com/

Just enter a URL of an image and click “create drawing” to being. The page will load that image into a hidden canvas and use it as reference to draw the picture. You should use Chrome of course but this should work in all HTML5 compatible browsers.

Room for improvement might be to place the code in an enclosure, cleaning up the global DOM namespace or multi-thread it this using Web Workers although the current speed is acceptable. Web Workers in this instance might be overkill.

Enjoy.

I spent some time last week looking at Web Sockets as a way to push information to the client. Web sockets need a custom server, not an HTTP server, so I used Nugget which is an open source implementation of the web socket protocol on CodePlex (http://nugget.codeplex.com/). Nugget worked great but with all the hype and interest around Node I felt I was missing something so I built the same thing again, this time around using Node.js on the server side.

Before get started you’ll need to build Node. This can be done

“on Linux, Macintosh, and Solaris. It also runs on Windows/Cygwin, FreeBSD, and OpenBSD. The build system requires Python 2.4 or better. V8, on which Node is built, supports only IA-32, x64, and ARM processors. V8 is included in the Node distribution. To use TLS, OpenSSL is required. There are no other dependencies.”

I used Cygwin on Wintel and installed g++, Python 2.7 and GNU Make. You also need OpenSSL if you plan on using Node with Web Sockets.

Here’s a comprehensive walkthrough of installing Cygwin and building Node from scratch: [LINK]

Web Sockets uses a funky little handshake protocol [LINK] to establish the connection which I didn’t feel like implementing so I came across a WS Server implementation using Node.JS up on GitHub [https://github.com/miksago/node-websocket-server/]. This worked well with Node 0.2.5 testing from Chrome 12 which uses v-76 of the Hixie protocol.

Here’s my client which is based off the Dive into HTML5 example:

if(Modernizr.websockets){
	    connect('ws://localhost:3400/service');
	} else {
		log ('web sockets not supported');
	}
	var ws;

	function connect(host) {
		ws = new WebSocket(host);
		ws.onopen = function () {
			log('connected');
		};

		ws.onmessage = function (evt) {
			log('recv :' + evt.data);
			showNotification(evt.data);
		};

		ws.onclose = function () {
			log('socket closed');
		};

		ws.onerror = function (evt) {
			log('<span style="color: red;">ERROR:</span> ' + evt.data);
		};
	};

	function log(msg){
		document.getElementById('log').innerHTML += msg + "<br/>";
	}

	function send(){
		var msg = document.getElementById('status').value;
		ws.send(msg);
	}

	function RequestPermission (callback) {
		window.webkitNotifications.requestPermission(callback);
	}

	function showNotification(msg){
		if (window.webkitNotifications.checkPermission() > 0) {
			RequestPermission(showNotification);
		}
		else {
			window.webkitNotifications.createNotification("alert.jpg", "Test Notification", msg).show();
		}
	}

With this client-side scripe and Node running the ws-socket server I was able to get a simple echo running forth between the web page and the server.

Node has gained some ground since I first looked at it (back when Chrome was on version 8). Even Microsoft has announced plans to port it over to Windows [LINK]. In the coming weeks I plan on looking at some of the templating engines (Like http://jade-lang.com/ and http://mustache.github.com/) and web frameworks (like http://expressjs.com and http://geddyjs.org/ ) which have cropped up around it and will report back on whether it’s ready for prime time or not. Watch this space.

Attribution: Today’s image by Casch52 on Flickr [LINK]

Typically they travel and branch along a source of nutrients, following the source. I came across this awesome work of Ryan Alexander [LINK] whilst messing around with Processing one evening. Ryan used Processing which is similar to Java. Processing is a great sketch-language which makes whipping up graphical wonders a doddle and is a favourite of interactive media artists. It’s really cool and I’ve been messing with it for a few years now. Check out “http://processing.org/” for more.

A few hours later I had the same thing implemented in Javascript and HTML5 using the Canvas element although mine is not as sophisticated as Ryan’s.

Disclaimer: I know nothing of Mycelium or of Hyphae or how they branch and form. I merely tried to emulate how the branching works.

Basically you take an image as input and a number of threads are created, I called them “worms” since “hyphae” seemed a but over the top. The worms have a trajectory and will move along it in search of food. Each iteration the worm decides where to move, favouring the light or dark portions of the image. Just as in Ryan’s Processing application the image acts as a source of food. If the worm ventures into a dark portion of the image, after a while without food, he dies.

I’m sure there’s a lot more to say on how this Mycelium stuff grows than what I’ve modeled here. For example I didn’t consider the amount of food contributing to the speed of the “worm” nor did I attempt to make the worms avoid each other. This was primarily an artistic endeavor and a creative outlet written over a beer one night.

I made a bunch of different images, Martin Luthor King, Bob Dylan, Willie Nelson, Clint Eastwood. For Clint’s I made a slight adjustment where any worm that died I’d re-spawn inside his eyes. Results were pretty nice. Here’s the Flickr Album: http://www.flickr.com/photos/10277648@N03/with/5704290009/

This technique works best on images with high-contrasting areas. Basically wrinkled old men. You’ll notice how the hyphae follow the wrinkles in Clint’s face.

Bob Dylan was surprising as the threads were never able to “break through” into the darker areas around his eyes. He just didn’t have enough wrinkles to feed them.

Willie Nelson, looking down. You can start to see his two braids forming in the weeds.

If you like these click over to the Flickr Album for more: http://www.flickr.com/photos/10277648@N03/with/5704290009/

Interesting factoid: At one point Mycelium was considered the largest living organism in the world! From Wikipedia:

This 2,400-acre (9.7 km2) site in eastern Oregon had a contiguous growth of mycelium before logging roads cut through it. Estimated at 1,665 football fields in size and 2,200 years old, this one fungus has killed the forest above it several times over, and in so doing has built deeper soil layers that allow the growth of ever-larger stands of trees. Mushroom-forming forest fungi are unique in that their mycelial mats can achieve such massive proportions.

In the coming days I’ll clean up the code and try to make it configurable so you can upload your own photos and play along. More to come on this one…

[UPDATE] Source code is now available here: http://francisshanahan.com/index.php/2011/mycellium-source-code-available/

If you’re building a website with a non-trivial CSS file (aren’t we all),  SASS  makes managing the CSS a lot simpler.

“Sass is a meta-language on top of CSS that’s used to describe the style of a document cleanly and structurally, with more power than flat CSS allows. Sass both provides a simpler, more elegant syntax for CSS and implements various features that are useful for creating manageable stylesheets.”

Sencha Touch uses SASS to manage its stylesheets. I’ve been researching this in my evenings and weekends and am at the point where I want to change how Sencha Touch looks. It’s not as simple as you’d think. Essentially I need to create a new theme. Hence a little SASS is warranted.

Unfortunately both the instructions on the Sencha site [LINK] and the SASS site [LINK] are a little out of date and buggy. Here now are the steps I followed to get this working on windows:

1. Start by installing Ruby – http://rubyforge.org grab the latest rubyinstaller-1.9.2-p136.exe – nothing to it and you’ll end up with c:\ruby192 and some Start-Menu items.
2. This comes with Gems so you can skips the gems install. There is one snag though with Ruby 1.9.2-p136 that the install sets up an incorrect folder – c:\ruby192\lib\ruby\site_ruby – remove this one (just rename it to be safe) and gems will work. Maybe they’ll fix this in the next release.
3. Install Compass: at a Ruby command prompt type “gem install compass”. If you’re behind a proxy I found this works: “gem install –http-proxy <proxyAddress:Port> compass”

Next create a new folder in your Sencha folders. If your directories look like this

c:\myWebsite\js\sencha-touch-1.0.1\resources\css

c:\myWebsite\js\sencha-touch-1.0.1\resources\sass

You’ll want to create this one:

c:\myWebsite\js\sencha-touch-1.0.1\resources\SCSS

Inside that create two files as per the Sencha website:

Config.Rb (a ruby file)

# Delineate the directory for our SASS/SCSS files (this directory)
sass_path = File.dirname(__FILE__)

# Delineate the CSS directory (under resources/css in this demo)
css_path = File.join(sass_path, "..", "css")

# Delinate the images directory
images_dir = File.join(sass_path, "..", "img")

# Load the sencha-touch framework
load File.join(sass_path, '..', '..', '..', '..', 'resources', 'themes')

# Specify the output style/environment
output_style = :compressed
environment = :production

No changes are needed to config.rb

Next create Application.scss(The file extension is important here)

// 1. Variable overrides, example:
// $base-color: #af2584;

// 2. Include Sencha Touch styles
@import 'c:\myWebsite\js\sencha-touch-1.0.1\resources\themes\stylesheets\sencha-touch\default\all';
@include sencha-panel;
@include sencha-buttons;
@include sencha-sheet;
@include sencha-picker;
@include sencha-toolbar-forms;
@include sencha-tabs;
@include sencha-toolbar;
@include sencha-carousel;
@include sencha-indexbar;
@include sencha-list;
@include sencha-layout;
@include sencha-form;
@include sencha-loading-spinner;

// 3. Define custom styles (can use SASS/Compass), example:
// .mybox {
//     @include border-radius(4px);
// }

The @import line is important. I changed it to the location of the default theme in Sencha Touch with the “all” appended.

Lastly, run SASS using “compass compile”. You’ll end up with a new file names “application.css” located under

c:\myWebsite\js\sencha-touch-1.0.1\resources\css\application.css

Now reference that new CSS file in your Sencha website and you’re all set. Refer to Sencha’s site for tips on customizing the Theme itself [http://www.sencha.com/blog/2010/12/17/an-introduction-to-theming-sencha-touch/].

SASS on its own is a boon if you’re doing serious CSS work. If not it’s probably over kill. You can do things like define variables and have those determine your CSS based on functions, you can nest elements for easier maintenance and even remove whitespace and combine multiple CSS files into one automatically.

Definitely one for the toolbox.

HTML5 introduces the ability to perform multi-threading in the browser using Javascript through the notion of “Web Workers”. So far I have only seen examples of using workers to calculate very high prime numbers. I took a fresh look at these from the standpoint of genetic algorithms and applied it to the Traveling Salesman Problem (a classic). The results are a multi-threaded implementation of the TSP in Javascript capable of converging on a solution for up to 200 cities, all with a zero-footprint.

This project was born on a plane over the Atlantic last week. With such a long title to this post I thought about breaking it up into multiple posts but got lazy and figured if you’re on this site to begin with, chances are you’re familiar with all these concepts already so here goes.

First a refresher:

The Travelling Salesman Problem (TSP) is an NP-hard problem in combinatorial optimization studied in operations research and theoretical computer science. Given a list of cities and their pairwise distances, the task is to find a shortest possible tour that visits each city exactly once.

The most direct solution would be to try all permutations (ordered combinations) and see which one is cheapest (using brute force search). The running time for this approach lies within a polynomial factor of O(n!), the factorial of the number of cities, so this solution becomes impractical even for only 20 cities.

http://en.wikipedia.org/wiki/Travelling_salesman_problem

Instead of Brute Force I will try to converge on the solution using a genetic algorithm.

At this point you may want to flip to the finished project using CHROME 7+ or Firefox 4+ or Opera 10+

http://francisshanahan.com/tsa/tsaGAworkers.htm

Genetic algorithms are those which can be said to exhibit the characteristics of evolution, i.e. a coded sequence, mutation, a fit function and iterative progression. The typical flow is as follows:

1. Develop a sequence of instructions (the DNA)
2. Develop a large number of these sequences (the population). In the code I called these “strands”.
3. Score the population for fitness.
4. Sort by fitness score and select the top-performers.
5. Generate a new population based off the top-performers.
6. Modify or mutate this new population and repeat the process with this new generation.

Over time the population will tend to converge on a solution. This is a genetic algorithm and it’s not guaranteed to give the absolute best solution. As you can guess the rate at which the population converges on the best solution is determined by a number of factors:

1. Population Size
2. Population diversity
3. Mutation Rate
4. Fitness Function
5. The number of generations
6. The number of “parents” selected to breed from.

A closely related process is that of “Hill Climbing”. Hill Climbing I would say is more deterministic (less probabilistic). A typical hill climbing algorithm is as follows:

1. Develop a sequence of instructions (the DNA)
2. Score the solution for fitness.
3. Modify or mutate this solution and score.
4. If the child is better than the parent it becomes the new parent.
5. Repeat the process (go back to step #2).

So what’s the difference? Well for one, with hill climbing we only ever advance if the new descendant is better than the current solution. With each generation you always converge. With a Genetic Algorithm you advance regardless and hope for convergence over time. Convergence in a GA is not assured.

A more subtle difference is that the Hill Climbing algorithm is fixed on a specific path. It always chooses a better solution, even though there is a chance that this vector will not ultimately result in the absolute solution. However in a GA, the algorithm chooses a set of “good” solutions to breed from, and hence includes the possibility that a current inferior solution might ultimately lead to a better absolute solution overall.

This GA approach mimics real evolution much more closely. It allows for the possibility that a currently superior branch might die off and yield to a currently inferior solution. I think of this as more of a “strategic” solution than a “tactical” hill climbing solution.

Applying GA to the Traveling Salesman Problem I ended up with this:

1. I create a set of random cities within a specific area.
2. Then I create a route through all cities (dna in the source code).
3. Then I score the route by calculating the overall length of the route.  A score + dna = a single strand.
4. Then I create a population of these strands.
5. I sort by fitness score and select the 5 best regardless of score.
6. I create a new generation based on these 5, mutating approximately 80% of the time.
7. A mutation is basically swapping two cities at random. There is no intelligence to the mutation.
8. Score this new generation and repeat the process (go back to step 5).

This works nicely and is pretty trivial code in Javascript involving a little bit of math and a lot of array copies. In order to get decent results for a problem space of 100 cities or more it’s necessary to to repeat this process for at least 20-50 generations at a time. All processing is sequential and the browser hangs up whilst this is going on. To achieve solutions to a higher number of cities some other means of processing is needed.

Enter web workers.

Web Workers are new in HTML5 and in a nutshell they allow you to execute Javascript in a separate thread (in parallel) from the current browser thread. So far Chrome, Opera, Firefox have all implemented web workers. ). I’m not going to explain the basics of workers here as Mozilla has an EXCELLENT explanation of how to get started here: https://developer.mozilla.org/En/Using_web_workers

I’m using them as follows:

1. Create a large population of possible solutions (my solution uses 1000)
2. Create a number of workers, my solution uses 10.
3. Split up the population across the workers, giving each 100 solutions to work on.
4. Mutate and score each one within the worker (10 threads operating in parallel).
5. Join back and Collect the results.
6. Sort the entire population and repeat.

Couple of advantages here are that not only do we get parallel execution and finish processing quicker, we don’t hang up the UI thread so the browser remains responsive throughout.

Web Workers are great for processing but little else. They cannot access the DOM, the cannot generate page events, they cannot do much of anything. What they can do is receive information from the parent page, process information and send it back. This information is limited to strings. You can serialize your objects to a json string and then do an eval on the worker side but this ultimately will be done for you by the browser. So far only Firefox and Opera are capable of serializing JSON objects between the page and the worker thread. Hence the example solution only works in these browsers.

A couple of things I noticed in working with this approach.

1. A larger population does not always guarantee a better solution. There is a balance for any given problem space and fitness function.
2. Mutation rate: You cannot simply change EVERYthing on each generation. You must maintain some of the core DNA in order to improve. Otherwise the solution is too random and does not converge.
3. Similarly, too little mutation and the solution converges too slowly.
4. Number of Breeders – you would think breeding from the single-best solution at any given point would be ideal. Surprisingly the system did better when a higher number, say 10% of the population is used to breed from. Too many and again you don’t converge. Too few and the system can be boxed into a dead-end solution ala the Hill Climbing approach.

The key thing to remember is at no point have I written an algorithm to find the shortest distance. I’ve simply put pieces together in a closed system, assigned probabilities and set the thing in motion. Even still it’s pretty fascinating.

Over the course of the past week I’ve run this thing many times. It’s the type of thing I can waste hours with. I tried various combinations of mutation rate, population size etc to get the right balance. Initially the system did not converge at all. Then I found it would converge but very quickly plateau and run out of ideas so to speak. Amping up the mutation fixed this but negatively impacted convergence, so I tweaked the number of breeders a little. Back and forth until I got it to where it is today. It’s fun to watch the code try to figure out new pathways, occasionally it’ll drop a segment in favour of a different route, only to bring that same piece back in later.  This is where my knowledge of GA falls short. I’m not sure I’ve gotten it right and to take it any further would require some heavy duty research. It’ll suffice for now.

This is a crude system with only 1 test for fitness and no competing goals. Imagine scaling this up to “earth” scale with billions of competing factors, each of varying weights, trillions of instructions per individual,  3.5 billion years of evolution and a system that feeds BACK on itself, altering the fitness functions as it goes. The possibilities are astounding.

As you can tell I had a lot of fun with this one. Genetic algorithms are a powerful concept, particularly when dealing with difficult to solve problems (e.g.  NP-hard). The outcome is highly probabilistic and how the algorithm progresses essentially mimics our own progression as life on planet earth. Too cool.

Now flip to the finished project using CHROME 7+ or Firefox 4+ or Opera 10+

http://francisshanahan.com/tsa/tsaGAworkers.htm

What’s the difference between the two blocks below?
Answer: One’s a canvas and the other are div tags.

This might not seem that interesting at first so here’s the interesting bit: The Div’s background is actually taken from the Canvas. There’s only one Canvas on the page so how’s that working?
Answer: A CSS class is dynamically created with its background set to the base64 output of the Canvas!

Yes, you can get the base64 encoding of any canvas element using canvas.toDataURL().

var base64 = canvas.toDataURL("image/png");

This was news to me but the connection was that the base64 data can then be used in a new CSS rule to with the data being the background, just like you’d do with a tiny image.

* Side note: It’s common to base64 encode images and directly embed them into the CSS file provided they are small enough. Base64 encoding is typically 33% larger than the binary data but you save the HTTP request. If you Sprite your images into one big file it’s less of a savings. Again, all things in engineering are a balance/compromise so do what makes sense for your situation.

var newClass = ".newClass{  background:url("+base64+");} ";
$("<style type='text/css'>"+size + newClass + "</style>").appendTo("head");

I then rotated the divs with CSS3 just for kicks.

<div style="-webkit-transform: rotate(-10deg); -moz-transform: rotate(-10deg); transform: rotate(-10deg);">Hello</div>

Here’s the relevant code all in one piece:

// grab the data
var base64 = canvas.toDataURL("image/png");

var newClass = ".newClass{  background:url("+base64+");} ";

$("<style type='text/css'>" + newClass +"</style>").appendTo("head");

$('#box div').addClass("newClass");

So why would you ever do this? I suppose you might do this to avoid creating a lot of smaller canvas tags. I haven’t checked but I’d wager the overhead for a canvas is higher than that of a CSS rule. You can create one canvas image and then use it all over the place with CSS.

You could implement rounded corners with this but it’s probably the most complex way of doing rounded corners ever so wouldn’t recommend it there either.

One possible use of this is to take a copy of an image as it’s being built. E.g. Canvas images are bitmaps and there’s no “undo”. Unlike SVG, they don’t modify the DOM so you can’t add and remove elements of the image. Imagine a graph built using Canvas, if the user modifies the graph it might be useful to take a copy of it before the modification. You could do this by dumping the base64 data and displaying as a CSS image, rather than creating a 2nd canvas element. I’m reaching here but you get the idea.

I’m not sure this will ever have a practical application. For now it’s just an interesting tech experiment and another example of the cool stuff possible with HTML5.

Identicon5 is a JQuery plugin that takes an MD5 hash and converts it to a unique image. It’s called Identicon5 since it works through the HTML5 Canvas element.

Working Demo is here: http://francisshanahan.com/identicon5/test.html

Project page is here: http://francisshanahan.com/index.php/identicon5

JQuery Plugin page is here: http://plugins.jquery.com/project/identicon5

Identicons provide a nice visual representation of a user’s identity, that’s unique to that user, without divulging any private information. You’ve probably seen them in use on many social websites e.g. http://stackoverflow.com

Identicons are the little geometrical profile images for certain users. Normally Gravatar.com serves up an image based off the MD5 hash of your email address. If you’ve defined a profile image it’ll serve that but if not it’ll show your Identicon, this blog itself is Gravatar enabled as are most WordPress installations.

EXCERPT from Wikipedia

An Identicon is a visual representation of a hash value, usually of the IP address, serving to identify a user of a computer system. The original Identicon is a 9-block graphic, which has been extended to other graphic forms by third parties some of whom have used MD5 instead of the IP address as the identifier. In summary, an Identicon is a privacy protecting derivative of each user’s IP address built into a 9-block image and displayed next the user’s name.

A visual representation is thought to be easier to compare than one which uses only numbers and more importantly, it maintains the person’s privacy.

The Identicon graphic is unique since it’s based on the users IP, but it is not possible to recover the IP by looking at the Identicon.

If you have page with a lot of Users listed, either because there are a lot of contributors on the thread, you might end up with a lot of Identicon image links. Each image is small, about 1kb and carries an HTTP connection as additional overhead. This isn’t really a big problem given today’s bandwidth on the Desktop but on my Droid it becomes an issue. Besides, with HTML5 we can do better.

Identicon5 takes the same MD5 hash value and draws the image dynamically using a Canvas element within the browser. This eliminates the HTTP call and saves you 1kb per profile image. If Canvas is not supported it’ll degrade into a standard img tag linking to Gravatar.

How does Quilting enter into it? Don Parks came up with the notion of using small tiles, arranged in a 3×3 grid per Identicon. The process uses a selection of smaller shapes in each 3×3 grid square and either rotates it or colors it depending on the input value. This is essentially how quilts have been made for hundreds of years.

I’m sure this won’t be the most popular jQuery plugin ever but the idea of applying newer technologies such as HTML5 Canvas to solve a problem that would traditionally have been fixed with a network call was very interesting to me so just had to hack it together.

This is a very tangible example of how HTML5 will make the web more scalable.