This tutorial will show you how to create a simple data structure for shapes on an HTML5 canvas and how to have them be selectable. The finished canvas will look like this:

Click to drag the shapes. Double click to add a new shape.

We’ll be going over a few things that are essential to interactive apps such as games (drawing loop, hit testing), and in later tutorials I will probably turn this example into a small game of some kind. The code also contains simple examples of using JavaScript prototypes and closures. I will try to accommodate JavaScript beginners but this introduction does expect at least a rudimentary understanding of JS. Not every piece of code is explained in the text, but almost every piece of code is thoroughly commented!

The HTML5 Canvas

A Canvas is made by using the <canvas> tag in HTML:

   <canvas id="canvas" width="400" height="300">
    This text is displayed if your browser does not support HTML5 Canvas.
   </canvas>

A canvas isn’t smart: it’s just a place for drawing pixels. If you ask it to draw something it will execute the drawing command and then immediately forget everything about what it has just drawn. This is sometimes referred to as an immediate drawing surface, as contrasted with SVG as a retained drawing surface, since SVG keeps a reference to everything drawn. Because we have no such references, we have to keep track ourselves of all the things we want to draw (and re-draw) each frame.

Canvas also has no built-in way of dealing with animation. If you want to make something that you’ve drawn move, you have to clear the entire canvas and redraw all of the objects with one or more of them in a new location. And you have to do it often, of course, if you want a semblance of animation or motion.

So we’ll need to add:

1. Code for keeping track of objects
2. Code for keeping track of canvas state
3. Code for mouse events
4. Code for drawing the objects as they are made and move around

The things we draw

To keep things simple for this example we will start with a Shape class to represent rectangular objects.

JavaScript doesn’t technically have classes, but that isn’t a problem because JavaScript programmers are very good at playing pretend. Functionally (well, for our example) we are going to have a Shape class and create Shape instances with it. What we are really doing is defining a function named Shape and adding functions to Shape’s prototype. You can make new instances of the function Shape and all instances will share the functions defined on Shape’s prototype.

If you’ve never encountered prototypes in JavaScript before or if the above sounds confusing to you, I highly recommend reading Crockford’s JavaScript: The Good Parts. The book is an intermediate overview of JavaScript that gives a good understanding of why programmers choose to create objects in different ways, why certain conventions are frowned upon, and just what makes JavaScript so different.

Here’s our Shape constructor and one of the two prototype methods, which are comparable to a class instance methods:

// Constructor for Shape objects to hold data for all drawn objects.
// For now they will just be defined as rectangles.
function Shape(x, y, w, h, fill) {
  // This is a very simple and unsafe constructor. 
  // All we're doing is checking if the values exist.
  // "x || 0" just means "if there is a value for x, use that. Otherwise use 0."
  this.x = x || 0;
  this.y = y || 0;
  this.w = w || 1;
  this.h = h || 1;
  this.fill = fill || '#AAAAAA';
}
 
// Draws this shape to a given context
Shape.prototype.draw = function(ctx) {
  ctx.fillStyle = this.fill;
  ctx.fillRect(this.x, this.y, this.w, this.h);
}

They are pretty self-explanatory. The shape constructor has “defaults” if you give it no arguments, and calling draw on a shape will set the fill and draw a rectangle on the given context corresponding to the measurements of the Shape.

Keeping track of canvas state

We’re going to have a second class (function) called CanvasState. We’re only going to make one instance of this function and it will hold all of the state in this tutorial that is not associated with Shapes themselves.

CanvasState is going to foremost need a reference to the Canvas and a few other field for convenience. We’re also going to compute and save the border and padding (if there is any) so that we can get accurate mouse coordinates.

In the CanvasState constructor we will also have a collection of state relating to the objects on the canvas and the current status of dragging. We’ll make an array of shapes, a flag “dragging” that will be true while we are dragging, a field to keep track of which object is selected and a “valid” flag that will be set to false will cause the Canvas to clear everything and redraw.

is going to need an array of Shapes to keep track of whats been drawn so far.

I’m going to add a bunch of variables for keeping track of the drawing and mouse state. I already added boxes[] to keep track of each object, but we’ll also need a var for the canvas, the canvas’ 2d context (where wall drawing is done), whether the mouse is dragging, width/height of the canvas, and so on. We’ll also want to make a second canvas, for selection purposes, but I’ll talk about that later.

function CanvasState(canvas) {
 
  // ...
 
  // I removed some setup code to save space
  // See the full source at the end
 
 
  // **** Keep track of state! ****
 
  this.valid = false; // when set to true, the canvas will redraw everything
  this.shapes = [];  // the collection of things to be drawn
  this.dragging = false; // Keep track of when we are dragging
  // the current selected object.
  // In the future we could turn this into an array for multiple selection
  this.selection = null;
  this.dragoffx = 0; // See mousedown and mousemove events for explanation
  this.dragoffy = 0;

Mouse events

We’ll add events for mousedown, mouseup, and mousemove that will control when an object starts and stops dragging. We’ll also disable the selectstart event, which stops double-clicking on canvas from accidentally selecting text on the page. Finally we’ll add a double-click (dblclick) event that will create a new Shape and add it to the CanvasState’s list of shapes.

The mousedown event begins by calling getMouse on our CanvasState to return the x and y position of the mouse. We then iterate through the list of Shapes to see if any of them contain the mouse position. We go through them backwards because they are drawn forwards, and we want to select the one that appears topmost, so we must find the potential shape that was drawn last.

If we find a shape then we want to select it. We save the offset, save a reference to that shape as the CanvasState’s this.selection, set this.dragging to true and set the this.valid flag to false. Already we’ve used most of our state! Finally if we didn’t find any objects we need to see if there was a selection saved from last time. Since we clicked on nothing, we obviously didn’t click on the already-selected object, so we want to “deselect” and clear the selection reference. Clearing the selection means we will have to clear the canvas and redraw everything without the selection ring, so we set the valid flag to false.

 
  // ...
  // (We are still in the CanvasState constructor)
 
  // This is an example of a closure!
  // Right here "this" means the CanvasState. But we are making events on the Canvas itself,
  // and when the events are fired on the canvas the variable "this" is going to mean the canvas!
  // Since we still want to use this particular CanvasState in the events we have to save a reference to it.
  // This is our reference!
  var myState = this;
 
  //fixes a problem where double clicking causes text to get selected on the canvas
  canvas.addEventListener('selectstart', function(e) { e.preventDefault(); return false; }, false);
  // Up, down, and move are for dragging
  canvas.addEventListener('mousedown', function(e) {
    var mouse = myState.getMouse(e);
    var mx = mouse.x;
    var my = mouse.y;
    var shapes = myState.shapes;
    var l = shapes.length;
    for (var i = l-1; i >= 0; i--) {
      if (shapes[i].contains(mx, my)) {
        var mySel = shapes[i];
        // Keep track of where in the object we clicked
        // so we can move it smoothly (see mousemove)
        myState.dragoffx = mx - mySel.x;
        myState.dragoffy = my - mySel.y;
        myState.dragging = true;
        myState.selection = mySel;
        myState.valid = false;
        return;
      }
    }
    // havent returned means we have failed to select anything.
    // If there was an object selected, we deselect it
    if (myState.selection) {
      myState.selection = null;
      myState.valid = false; // Need to clear the old selection border
    }
  }, true);

The mousemove event checks to see if we have set the dragging flag to true. If we have it gets the current mouse positon and moves the selected object to that position, remembering the offset of where we were grabbing it. If the dragging flag is false the mousemove event does nothing.

  canvas.addEventListener('mousemove', function(e) {
    if (myState.dragging){
      var mouse = myState.getMouse(e);
      // We don't want to drag the object by its top-left corner,
      // we want to drag from where we clicked.
      // Thats why we saved the offset and use it here
      myState.selection.x = mouse.x - myState.dragoffx;
      myState.selection.y = mouse.y - myState.dragoffy;   
      myState.valid = false; // Something's dragging so we must redraw
    }
  }, true);

The mouseup event is simple, all it has to do is update the CanvasState so that we are no longer dragging! So once you lift the mouse, the mousemove event is back to doing nothing.

  canvas.addEventListener('mouseup', function(e) {
    myState.dragging = false;
  }, true);

The dblclick event we’ll use to add more Shapes to our canvas. It calls addShape on the CanvasState with a new instance of Shape. all addShape does is add the argument to the list of Shapes in the CanvasState.

  // double click for making new Shapes
  canvas.addEventListener('dblclick', function(e) {
    var mouse = myState.getMouse(e);
    myState.addShape(new Shape(mouse.x - 10, mouse.y - 10, 20, 20,
                               'rgba(0,255,0,.6)'));
  }, true);

There are a few options I implemented, what the selection ring looks like and how often we redraw. setInterval simply calls our CanvasState’s draw method. Our interval of 30 means that we call the draw method every 30 milliseconds.

  // **** Options! ****
 
  this.selectionColor = '#CC0000';
  this.selectionWidth = 2;  
  this.interval = 30;
  setInterval(function() { myState.draw(); }, myState.interval);
}

Drawing

Now we’re set up to draw every 30 milliseconds, which will allow us to continuously update the canvas so it appears like the shapes we drag are smoothly moving around. However, drawing doesn’t just mean drawing the shapes over and over; we also have to clear the canvas on every draw. If we don’t clear it, dragging will look like the shape is making a solid line because none of the old shape-positions will go away.

Because of this, we clear the entire canvas before each Draw frame. This can get expensive, and we only want to draw if something has actually changed within our framework, which is why we have the “valid” flag in our CanvasState.

After everything is drawn the draw method will set the valid flag to true. Then, ocne we do something like adding a new Shape or trying to drag a Shape, the state will get invalidated and draw() will clear, redraw all objects, and set the valid flag again.

// While draw is called as often as the INTERVAL variable demands,
// It only ever does something if the canvas gets invalidated by our code
CanvasState.prototype.draw = function() {
  // if our state is invalid, redraw and validate!
  if (!this.valid) {
    var ctx = this.ctx;
    var shapes = this.shapes;
    this.clear();
 
    // ** Add stuff you want drawn in the background all the time here **
 
    // draw all shapes
    var l = shapes.length;
    for (var i = 0; i < l; i++) {
      var shape = shapes[i];
      // We can skip the drawing of elements that have moved off the screen:
      if (shape.x > this.width || shape.y > this.height ||
          shape.x + shape.w < 0 || shape.y + shape.h < 0) continue;
      shapes[i].draw(ctx);
    }
 
    // draw selection
    // right now this is just a stroke along the edge of the selected Shape
    if (this.selection != null) {
      ctx.strokeStyle = this.selectionColor;
      ctx.lineWidth = this.selectionWidth;
      var mySel = this.selection;
      ctx.strokeRect(mySel.x,mySel.y,mySel.w,mySel.h);
    }
 
    // ** Add stuff you want drawn on top all the time here **
 
    this.valid = true;
  }
}

We go through all of shapes[] and draw each one in order. This will give the nice appearance of later shapes looking as if they are on top of earlier shapes. After all the shapes are drawn, a selection handle (if there is a selection) gets drawn around the shape that this.selection references.

If you wanted a background (like a city) or a foreground (like clouds), one way to add them is to put them before or after the main two drawing bits. There are often better ways though, like using multiple canvases or a CSS background-image, but we won’t go over that here.

Getting mouse coordinates on Canvas

Getting good mouse coordinates is a little tricky on Canvas. You could use offsetX/Y and LayerX/Y, but LayerX/Y is deprecated in webkit (Chrome and Safari) and Firefox does not have offsetX/Y.

The most bulletproof way to get the correct mouse position is shown below. You have to walk up the tree adding the offsets together. Then you must add any padding or border to the offset. Finally, to fix coordinate problems when you have fixed-position elements on the page (like the wordpress admin bar or a stumbleupon bar) you must add the <html>’s offsetTop and offsetLeft.

Then you simply subtract that offset from the e.pageX/Y values and you’ll get perfect coordinates in almost every possible situation.

// Creates an object with x and y defined,
// set to the mouse position relative to the state's canvas
// If you wanna be super-correct this can be tricky,
// we have to worry about padding and borders
CanvasState.prototype.getMouse = function(e) {
  var element = this.canvas, offsetX = 0, offsetY = 0, mx, my;
 
  // Compute the total offset
  if (element.offsetParent !== undefined) {
    do {
      offsetX += element.offsetLeft;
      offsetY += element.offsetTop;
    } while ((element = element.offsetParent));
  }
 
  // Add padding and border style widths to offset
  // Also add the <html> offsets in case there's a position:fixed bar
  offsetX += this.stylePaddingLeft + this.styleBorderLeft + this.htmlLeft;
  offsetY += this.stylePaddingTop + this.styleBorderTop + this.htmlTop;
 
  mx = e.pageX - offsetX;
  my = e.pageY - offsetY;
 
  // We return a simple javascript object (a hash) with x and y defined
  return {x: mx, y: my};
}

At long last

From here its just a few lines to draw some shapes to move around. We make one instance of CanvasState, passing it a reference to the canvas we want to use, then we can add any number of new shapes to it. The code below produces the example at the top of this page:

var s = new CanvasState(document.getElementById('canvas1'));
s.addShape(new Shape(40,40,50,50)); // The default is gray
s.addShape(new Shape(60,140,40,60, 'lightskyblue'));
// Lets make some partially transparent
s.addShape(new Shape(80,150,60,30, 'rgba(127, 255, 212, .5)'));
s.addShape(new Shape(125,80,30,80, 'rgba(245, 222, 179, .7)'));

There are a few little methods I added that are not shown, such as Shape’s method to see if a point is inside its bounds. You can see and download the full demo source here.

Now that we have a basic structure down, it is easy to write code that handles more complex shapes, like paths or images or video. Rotation and scaling these things takes a bit more work, but is quite doable with the Canvas and our selection method is already set up to deal with them.

If you would like to see this code enhanced in future posts (or have any fixes), let me know.

It’s just reached midnight in New Hampshire, and “yesterday” the Galaxy Nexus was released for Verizon in the United States.

I’m sure to lots of people this is just yet-another-android-phone. Or for many its simply an upgrade from one gadget to the next. People will yawn, or fawn, or get on with their lives with or without it. I myself would probably be pleased as Punch with just about any modern smartphone.

Yesterday I bought a Galaxy Nexus, my first smartphone and second-ever cellphone.

Learning to set my alarm for tomorrow morning, I find myself reflecting. I really am completely in awe. Starstruck. I am a computer person, and here is a thing more powerful than most of the computers I have ever owned.

In New Hampshire 4G was rolled out Wednesday or so my coworkers tell me. The data capabilities of the phone are impressive to me, but then again 56k speeds on the phone would not be any less impressive. How could they be?

Somehow I have made it almost to 2012 without owning a GPS or an MP3 player or a pocket camera. It’s not that I’m against them, I just never found much need. Now I have a device with a scope and power so large I cannot believe it is this small.

The age of “wondering why” is over. This is instant portable access to the largest knowledge and communication infrastructure in the world. A rough approximation of the sum of human knowledge is literally carried along in my pocket. I can express and communicate and learn from anywhere. At my desk, in my bed, on the road, in the woods.

How is this not the most amazing thing?

The rules for what one can and cannot do are laid out in the spec, though the reasoning behind them isn’t so obvious. The most typical violation is when a programmer uses drawImage() with an image that is from a different domain (than the page that the canvas is on) or an image that is on the local file system. When drawImage() is used in one of these two ways, the canvas internally sets its origin-clean flag to false.

From the moment a canvas has its origin-clean flag set to false one is not allowed to use the getImageData() and toDataUrl() methods of that canvas, instead the security error will be thrown. There are a few more cases where the origin-clean flag will be set to false, you can read about them in the spec here.

The reason for this security is to prevent something called information leakage. To see why this is a security issue, consider the following hypothetical situation:

Say you are on a work network and so you have access to internal, private company sites and your (private!) hard-drive. You can accessThe private sites might be something like www.internal.myCompany.com and your hard drive would be accessible from urls like file:///C:/SomeOfMyPhotos/.

Now suppose you visited a website with a hidden canvas and while you were browsing the site that canvas was constantly calling drawImage() onto that canvas with urls that it was guessing might exist. These urls would be things like an image on the private subdomain:

www.internal.myCompany.com/secret/secret-plans.jpg

Or an image on your hard drive:

file:///C:/SomeOfMyPhotos/thatEmbarassingPhoto.png

The malicious site could keep trying different combinations of private-to-you urls until it found one that was actually a file. Then it would draw it to the canvas. Then it would get the imageData from the canvas and send it off to the server.

Voila! The malicious site owner now has your secret plans and your embarrassing photos, much without your consent.

Now we know that the above scenario is not very probable: In the real world, secret plans are almost always in PNG format whereas embarassing photos are almost universally in JPG format! But it stands that situations like the above could happen and so the security implications of canvas must take this into account.

I’ve made this easier by creating a simple Transform class for use with Canvas. You can have a look at it here.

It has all of the Canvas equivalents, and can be used alongside canvas to record the matrix state or can be used instead of and then applied to the canvas.

In other words, a start-to-finish use of the Transform would be like this:

var t = new Transform();
t.rotate(5);
var m = t.m;
ctx.setTransform(m[0], m[1], m[2], m[3], m[4], m[5]);

Which will do the exact same thing as this:

ctx.rotate(5);

Or the shorter:

var t = new Transform();
t.rotate(5);
ctx.rotate(5);

But of course allow you to keep track of it!

If you wanted, you could easily call the class to take a context and always do the operations when it is called.

Much of the functionality of Canvas comes from its path drawing functions. Unfortunately for game designers and animators, re-drawing paths over and over can amount to a tangible performance hit. To increase performance, let’s take a look at caching paths as images to avoid redrawing them traditionally.

Gentlemen waiting for a path to finish rendering

First we need to ensure that caching a path will actually lead to a performance increase. We can devise a simple test for this using JSPerf. We need a path to test, so let’s write something fairly simple.

ctx.beginPath();
ctx.strokeStyle = 'red';
ctx.lineWidth = 4;
ctx.moveTo(10,10);
ctx.lineTo(10,30);
ctx.lineTo(30,30);
ctx.lineTo(40,70);
ctx.quadraticCurveTo(72,43,22,12);
ctx.quadraticCurveTo(12,43,12,102);
ctx.stroke();

This does not produce a particularly complex or exciting path:

But it will do.

The thing we want to ponder here is whether redrawing this path, in other words executing every one of the instructions needed to make the path, will be a slower process than if we cached it. We can achieve caching by drawing the path from these instructions only once, to an in-memory canvas, and then using drawImage from our in-memory canvas onto our real canvas to redraw the path.

That isn’t the only way to cache. We could instead draw it to a canvas and then make a PNG out of it, and call drawImage from that PNG instead, but for the sake of making a simpler test we will stick with using an in-memory canvas.

So let us take all of the drawing instructions above and execute them on the in-memory canvas. Then in our draw loop, instead of drawing out the path every time, we simply draw the in-memory canvas to our real canvas:

// can2 is our in-memory canvas
ctx.drawImage(can2, 0, 0);

The test is simple enough. Giving it a go, the results are immediately clear: pre-rendering and using drawImage is more than ten times as fast as drawing the path, even for the relatively simple path used!

The more complex the path, the more time you will save with caching. If you’re using a lot of complex paths to render shapes, such an optimization ought to speed up your draw loop by a great deal. The JSPerf page shows a simple setup if you want to make the test for yourself.

Other considerations

Pre-rendering paths isn’t a magic bullet, there are still a lot of uses for drawing paths constantly in canvas. If you are making a live drawing application, or otherwise constructing dynamic paths and/or moving and animating paths on the fly, then any kind of pre-rendering is going to be nearly pointless or even harmful to performance. After all, what’s the use of drawing something to a separate canvas and drawing that state back to the original canvas if the path changes constantly? You’d need to re-draw the in-memory canvas just as often, so you’d lose all benefit.

It is also worth mentioning that you might want to play around with using PNGs instead of in-memory canvases. Another thing to test is putting multiple paths onto one in-memory canvas versus putting them all in their own separate canvases, effectively making a sprite sheet. From previous tests, it seems that there is a slight advantage to giving each sprite its own png instead of using a single-png (or single in-memory canvas) sprite-sheet, but it wasn’t that big of a difference.

If you do choose to use a sprite sheet, note that there are a lot of decent tools out there for compressing and organizing them, such as Sprite Sheet Packer.

But after several days of having Google+ I realized something: Every single day since I’ve had it I have gotten at least some new Google+ notifications, as 4 or 5 more people add me per day.

In other words, a day has yet to go by where Google+ has not reminded me of its existence. A day has yet to go by where I have not wandered over to Goole+ to see whats up with the newcomers.

Instead of signing up, looking around to see what there is to see, then perhaps not logging back in for a week or a month, the trickle of Google+ invites is causing me to go look around at least once a day.

I’m beginning to think that the invites were actually a calculated move to keep the initial users coming back, welcoming their friends as they join and “showing them around” so to speak, all the while adding more activity to Google+.

Instead of creating a flash-mob that might have dispersed after a month or two, Google has created a pilgrimage. Very clever, I think, if intentional.

I’m considering writing a small (e-)book on Canvas performance issues, considerations and tips. If you’d be interested in that sort of thing, let me know.

As much as we all like to see dramatic performance increases from clever optimizations, getting the best Canvas performance often means scrutinizing every little place in our code. Today we’ll take a look at how canvases are cleared.

A man’s careful search for his receding hairline

One of the ways that is implicitly endorsed in the spec and often used in people’s apps to clear a canvas is this:

canvas.width = canvas.width;

There is of course another common way to clear the canvas using a context method:

ctx.clearRect(0, 0, canvas.width, canvas.height);

They may seem to do the same thing on the surface, but the end difference between the two methods is large: Setting the canvas width to itself not only clears the canvas, it clears all canvas state. This means it clears the transformation matrix, the current clipping region, and all of the following attributes: strokeStyle, fillStyle, globalAlpha, lineWidth, lineCap, lineJoin, miterLimit, shadowOffsetX, shadowOffsetY, shadowBlur, shadowColor, globalCompositeOperation, font, textAlign, and textBaseline.

Much of the time clearing above doesn’t matter, except maybe the transformation matrix, because canvas programmers tend to set the relevant properties before they redraw each shape anyway.

The performance difference between the two above methods is also large, often an order of magnitude or more. The context’s clearRect method is much faster than setting the canvas width to itself. I have a jsperf page up here where you can see the results per browser.

Curiously, clearRect is faster on every browser except Safari on Windows, where it is the other way around. I can think of a few possible reasons why that might be the case, but I don’t want to speculate out loud. If someone on a Mac could test Safari for me, I’d be interested to know what it benches.

Back to clearRect. Not all is well all the time when using this method. After all, if your canvas context has anything but the identity transform, there’s a good chance you won’t be clearing the entire canvas. This leads some people to end up erroneously using the width-setting method. Additionally, many people want to clear the canvas but keep their transformation matrix the same. Both of these problems can be fixed in one go, so in the interest of completeness, lets see a safer way:

// I have lots of transforms right now
ctx.save();
ctx.setTransform(1, 0, 0, 1, 0, 0);
// Will always clear the right space
ctx.clearRect(0, 0, canvas.width, canvas.height);
ctx.restore();
// Still have my old transforms

Not only does it clear the screen, but it ensures that any existing transformation won’t get in the way, and also allows you to keep that transformation should you need it. If you don’t need the transformation, you can of course remove the calls to save() and restore().

Because of the large performance discrepancy, I tentatively suggest the use of clearRect over setting the canvas width equal to itself, though the canvas width method is still useful for doing a complete reset of the context state. Of course, browser development happens rapidly and you should always test on the browsers and systems you are targeting.

The charge? Performance murder.

drawText() resisting arrest

I suspected drawText() of being slow ever since adding blocks of text as interactive objects to a Canvas library I am working on. I’ve also begun writing a canvas performance guidebook, so the sacrament of confirmation was doubly in order.

Since most of the slowness in canvas applications isn’t drawing something once, but redrawing it many times per second, I wondered if there were a faster way to redraw text than using the Canvas context’s drawText() method.

This is especially pertinent when drawing vertical text, since every new letter has to be on another line, and thus another call to the drawText() method.

I puzzled around with ways to avoid all the calls, and settled on trying something: Instead of calling drawText() to redraw my text objects each frame, I would instead create a new canvas (one never added to the DOM) for every single text object, and call drawText() on each object only once, drawing the text to its personal canvas.

Then, every time I wanted to (re)draw that text object, I would call drawImage() on my real canvas, passing in the object’s personal canvas, instead of using drawText(). This gives exactly the same per-pixel drawing, but is it faster?

I wrote a small, distilled test for the purpose, hypothesizing that it probably wasn’t worth doing for normal text but may be worth doing for vertical text. There’s a link at the end if you’re interested in trying it yourself.

There are a lot of scenarios though: What if I had just one text object that had to be redrawn 60 times a second? Surely – if drawImage() is faster than drawText() – having an additional canvas would be a small price to pay in overhead.

But what if I had 200 text objects? Maybe each text object having a canvas would cause it to be far slower.

I won’t bore you much longer, the definitive answer is this: If you are redrawing several text objects more than just a few times, it is far faster to give each object its own canvas and use drawImage() instead of drawText(). Not just for vertical text, but for any text, even if its just drawing a single character.

Some of the tests are described below in my poorly-made graphs. The first row of graphs are closer to real-use scenarios. Please note the Y-axis range (milliseconds) changes from graph to graph.

As you can see, drawing a text object of just 1 character several hundred times is far faster in Chrome, Firefox and, IE9 when using drawImage(), and thus very much worth it to have that extra canvas around.

The second row of graphs were some fooling around to find the limit of this method’s utility. If you have 200 text objects (and thus 200 additional canvases) of just 1 character each, and render them only once, using drawImage() becomes a bit of a waste. But drawing those 200 objects merely three times and you can see that it will be faster in chrome to use drawImage() than to use drawText(). Firefox and IE9 are a little more resilient here, but they don’t take very long at all for drawImage() to become worth it.

So giving each text object its own Canvas is a pretty workable solution even if the objects are redrawn very few times. If you are trying to achieve 30 frames per second, giving each text object its own Canvas and using drawImage() is a no-brainer, and should probably a default consideration.

Of course Canvas applications can differ wildly, and you should draw up tests for your own situation before deciding how to draw text. Perhaps exceptionally large canvases or exceptionally small text yield different results, or perhaps memory on the targeted machine means that so making so many canvases are an untenable proposition, and so on.

Here’s a link to the test I made. I would of course appreciate any corroboration of results that anyone is willing to do.

EXTRA CREDIT:

You’d need to do more work to get this to work with scaling text, since you’d have to size the temporary canvases appropriately. It does however have the added benefit of fixing the scaling + rotating text bug that currently exists in Chrome and Opera.

Because so many people attempt to introduce a classical structure to their Javscript code, I figure I’ll share some of my findings. Below is one way of allowing a base class function to copy an instance of a subclass while maintaining proper type.

Let’s say we have an Animal class and we subclass it to create a Cat class. We also want the Animal class to have a clone() method that will return work with its subclasses. That is, if I clone a Cat, I want “instanceof Cat” and “instanceof Animal” to both be true.

Let’s make the classes real quick. Here’s an Animal:

function Animal() {
  // animal stuff
}
 
// All of Animal's methods will go into its prototype
Animal.prototype = {
  saySomething: function() {
    return "I am an animal!";
  },
 
  copy: function() {
    var newcopy;
    if (this.subConstructor) {
      newcopy = new this.subConstructor;
    } else {
      newcopy = new Animal();
    }
 
    // maybe copy over other values
 
    return newcopy;
  }
};

And then the Cat. Typically the easiest way to make a Javascript function be a “subclass” of another function is to set the prototype of the subclass equal to “new baseclass.” With cat we’ll go a little further and also save the constructor.

Cat:

function Cat() {
  Animal.call(this); // call animal's constructor
  // cat stuff
}
 
// See below
derive(Animal, Cat)
 
// override the saySomething function
Cat.prototype.saySomething = function() {
  return "Meow!";
};

There you have it. Cats created this way will be “instanceof Cat” and “instanceof Animal”, and so will their clones. We should of course make tests to see, and lucky for us all of them check out OK:

// some tests and their results in the comment
 
var c = new Cat();
console.log(c instanceof Animal);   // true
console.log(c instanceof Cat);      // true
console.log(c.saySomething());      // "Meow!"
 
var a = new Animal();
console.log(a instanceof Animal);   // true
console.log(a instanceof Cat);      // false
console.log(a.saySomething());      // "I am an animal!"
 
var copyCat = c.copy();
console.log(copyCat instanceof Animal); // true
console.log(copyCat instanceof Cat);    // true
console.log(copyCat.saySomething());    // "Meow!"
 
var copyAnimal = a.copy();
console.log(copyAnimal instanceof Animal); // true
console.log(copyAnimal instanceof Cat);    // false
console.log(copyAnimal.saySomething());    // "I am an animal!"

You might want to use the four lines needed for subclassing elsewhere so its a good idea to stuff them into a function that you’d put in a utility class/var somewhere. So we could make:

function derive(baseclass, subclass) {
    function subproto() {}
    subproto.prototype = baseclass.prototype;
    subclass.prototype = new subproto();
    subclass.prototype.constructor = subclass;
}

And then making a clone-able subclass would be as easy as calling derive after each constructor:

function Cat() {
  this.constructor(); // call animal's constructor
  // cat stuff
}
 
derive(Animal, Cat);
 
// override the saySomething function
Cat.prototype.saySomething = function() {
  return "Meow!";
};

The contents were minimal: One laptop, one battery, one charger, one single page instruction card and one business card from Intel.

Challenge accepted.

The exterior of the laptop has been detailed by plenty of others, so I won’t get into that. gdgt.com already has a decent page on it.

But before I started to really use it I wanted to poke around inside. Looking over the external didn’t yield anything interesting: Just a few screws. Oh, and this?

To the right of the battery connector was a tiny black piece of tape-like material. Peeling it away revealed a small switch. For the sake of curiosity I flipped it.

Uh oh. Apparently the switch controls something memory related. (note that there’s no hard drive in the Cr-48, just flash memory).

I turned the computer off and turned the switch back, hopeful that I might not have totally destroyed Google’s gift. Thankfully, it seems to have a way to reset itself.

I had to re-enter my wireless password and login credentials, but otherwise the notebook was back to “new.” Not that there’s much of a difference – one of the things Google is trying to tout here is how easily one can change computers and still keep all of one’s “stuff” in order.

Despite taking out all the bottom (and behind-the-foot) screws the laptop would not come apart, at least with gentle amounts of pressure. I wasn’t keen on continuing further without first having a few days of experiencing the OS, so seeing the Atom Inside will have to wait.

On the actually-using-the-product side of things, I’ve really enjoyed it so far. The keyboard is unorthodox, but mostly suited to a browser-only experience. The F1-F12 are gone in favor of a set of laptop+browser specific keys. Unfortunately, the page-up/down keys are forgone in favor of ALT + Up/Down. Similarly, the delete key is hidden. I didn’t see any way to get home/end functionality, which unfortunately are necessary for any real writing in my common usage of computers.

I was surprised to see that Chrome OS is really nothing but Chrome. No file browser, no terminal (EDIT: Yes there is! Press CTRL+ALT+T for a very limited terminal), no desktop, just a web browser. For most users this is enough, since I suspect that the majority of computer users in the world use a web browser, a word processor, and a chat client or two, all of which can now have counterparts that exist in the browser. I think it would have great potential as a writing laptop were it not for the loss of the dedicated home/end/delete keys.

After using the Cr-48, it almost seems silly that netbooks attempt to be full computers. Google’s beta laptop instead seems to be what netbooks should have been from the start: a platform for all the thousands of browser apps, big and small, that make up the vast majority of common user’s tasks and games, without any of the complications or cruft of an entire operating system dragging its feet around.

ChromeOS is certainly no Windows/Ubuntu/OSX replacement, but with both WiFi and cellphone-network enabled internet as options, I think it will be a great little thing to bring around, from cafes to traveling. Certainly better than my powerhouse HP Envy, after all, since I’m not going to be playing much Starcraft 2 while drinking soup and coffee or touring Belgium.

Instead I’ll be reading email and the paper and reddit, or any number of things that I do on computers most of the time, all from a browser that just happens to be an operating system.