It is quite interesting to see how technology moves in circles. With canvas being the new fun toy to play with for creating browser-based games we have to find solutions to fake a 3D environment to be really fast (sure there is Canvas 3D but it is overkill for most games). The trick is to dig into the tricks arsenal of old-school game development on machines full of win like the Commodore 64 or Amiga.
The Freeciv.net crew has benchmarked a path in their canvas game. It is one data point, and tests more than just Canvas itself because a lot of code is running in the game. Thus, it ends up testing the union of a particular JavaScript path and the rendering of the canvas.
Here are the results:
With Bespin we had slightly different results, and the bulk of the bottleneck was in the blitting of the canvas. Optimizations were made to canvas over the initial phase of Bespin so the various browsers would leap frog each other. Good times :)
Steve Hanov has produced a Canvas-based drawing tool with a hand-drawn look. Lines can be drawn with a "sloppiness" option, with possible values "Draftsman", "Artist", "Cartoonist", "Child", and - perfect for this time of year - "Drunk" :). The FG Virgil font, applied to text elements, adds to the cartoon vibe.
The infamous Christian Effenberger has a new library to share:
TransM.js 1.0 allows you to add programmable image transitions to your webpages. Features 113 transitions, 32 tweenings, individual corners, overlay graphics and event actions. Requires no plugin/extension or any other external resource! It uses unobtrusive javascript to keep your code clean.
Andreas Ritter has managed to encode JPEGs in Javascript. This blog post explains how he did it, shows some benchmarks, and provides a demo and a downloadable library so you can play along at home.
It was surprising that it was that easy to get the first js-encoded jpeg displayed in the browser. Of course I didn't want to stop there. I wanted to optimize things as much as I could to make the encoder fast. This took me several days. I found optimized encoder versions for flash and haxe floating around the net (Faster JPEG Encoding with Flash Player 10) and tried the optimizations used there in my javascript version. As you can seen in the benchmarks below I was quite successful.
Another idea was to use the new web workers to do the heavy lifting in an separate thread, not blocking the gui. This is something flash can't do. So I created a version using a web worker for the encoding.
The API gives you a JPEGEncoder or an alternative JPEGEncoderThreaded. Usage is straightforward:
var JPEGImage = myEncoder.encode(CanvasPixelArray,[quality])
I think the results show that JavaScript is quite fast (at least in Safari and Chrome). A little over 4 seconds for the non-threaded version is a very good [sic] result, when compared to the 3,3 seconds the optimized flash jpeg encoder takes. Please note, that JavaScript has no static types, no byte array, no Vector-class and is not pre-compiled. Taking these facts into account Nitro and V8 are faster than the ActionScript 3 VM.
Comparing the different browsers Nitro and V8 are a magnitude faster than TraceMonkey. Firefox 3.6b2 shows some improvements, but it's still a long way. Probably the Mozilla guys should consider adopting Nitro or V8?
Eliot Graff of Microsoft wrote to public-html@w3.org:
In his mail describing why he created a separate Canvas 2D API specification, Doug Schepers wrote [1]:
> There is a chance that currently Canvas could be a blocker on progress
> for the HTML5 spec, and at this point, Canvas is so widely implemented
> that I don't think it's at risk, so I hope this isn't disruptive. I am
> available to help with any editing that needs doing, but I hope that
> others will also work with this draft, and step into the editor role.
At Microsoft, we agree with the sentiments expressed by Doug, Maciej [2], and others about creating a separate Canvas 2D API specification. [3] We are prepared to offer editorial resources to aid in the completion of this separate specification. We have looked over Doug's initial document, made some editorial enhancements, and are prepared to follow through in taking feedback and maintaining the specification.
We believe that some sort of accessibility API functionality is needed in the canvas element. However, the exact nature and depth of that functionality presents a dilemma that may block progress on the HTML5 spec. We also think that the Canvas 2D API may be a desirable feature used in other technologies such as SVG.
Starting with Doug Schepers' initial draft, we made changes to get the document to adhere to the W3C PubRules [4], enhance readability, and improve logical flow of the document. In addition, we foresee adding sample code throughout the specification, where appropriate. No normative changes have been made. As with all drafts, the Canvas 2D API specification is still a work in progress. We would like to solicit feedback about the changes that were made (see below TODO) and about further changes that the working group would like to see.
Our updated version is published at http://dev.w3.org/html5/canvas-api/canvas-2d-api.html.
It's still early work but James Urquhart has gotten HTML rendering inside the Canvas tag. In his demo, he renders the following HTML into the Canvas element:
Much of the real work involves regular expressions plus using the Canvas measureText and fillText functions. Right now he is parsing the following tags: HTML, BODY, P, B, and SPAN.
Martin Kool describes some of the long process it took to get these into the shape they are:
In 2003, I created Good Old Adventures. It was a chat environment set in the Sierra worlds without actual gameplay. All images were manually crafted, copy/pasting from WinAGI Game Development Studio. A time consuming process.
Four years later I wrote a few conversion tools in .NET to extract Sierra's in-game images and objects from the original games, and display them properly on the web. The "only thing" left to do then was to export and understand all in-game logics.
I was able to convert the logic to javascript, but there was one big problem: Sierra's code used GOTO statements, and those could jump anywhere in the code, even inside a nested "if"-statement. It seemed unsolvable in javascript.
I sat down together with Sjoerd Visscher, one of my collegues at Q42, and we came up with a solution. Using a decompilation approach to get rid of nested "if"-statements and putting the whole shebang inside a huge switch/case statement, we could mimic line numbers and GOTO's while maintaining performance. World domination was within reach :-D
It was halfway 2008 when I started to work on it, and Sarien.net is the result.
I'm a fan of all the new ways of drawing on the web. I consider myself a Canvas evangelist, an SVG evangelist, and an evangelist for the new CSS Animation work going on. When asked "SVG or Canvas" I've long felt the right answer is: "Yes" :) Canvas is great at pixels, SVG is great at vectors, 'nuff said. Give me my scriptable image tag (Canvas) AND my easy scene graph (SVG).
Along these lines, I was delighted to attend a recent presentation by Samuli Kaipiainen and Matti Paksula from the University of Helsinki at SVG Open 2009. In their paper (which I recommend reading) they show all sorts of cool results concerning Canvas and SVG, but two results jumped out at me in particular.
First, they showed apps built with SVG that should have used Canvas and vice versa to identify when to use one or the other. They showed a Jigsaw Puzzle program written in Canvas that should have used SVG, as the Canvas version took 2800 (!) lines of JavaScript essentially recreating the scene graph and rotations that SVG gives you for free:
They then showed a Space Invaders game written with SVG that obviously should have used Canvas instead: there's no mouse interaction, it's keyboard driven, and it needs rapid pixel-based updates since it's a game:
Second, both developers point out a nifty trick and snippet of code that I'm sure will become a regular part of peoples' work. They convert a Canvas image into a form that can be brought right into SVG by turning it into a data URL:
This would be useful for drawing a fancy background with Canvas, for example, and then pulling that onto an SVG element so you get an easy scene graph and scalable graphics. Samuli and Matti report that this technique works on all browsers (but not IE unfortunately, even with ExCanvas, as that currently doesn't support toDataURL yet).
Samuli and Matti end their paper with the following quote:
Based on these findings, there really is no vs. situation. The right technique needs to be selected for the job, and we hope this paper gives a good starting point for that. When the right choices are made, SVG and Canvas can actually benefit from each other...
Yes, there's a limit on each standard's capabilitiness. For pixel flare and other "demo effects", go with Canvas. For intrinsic shapes and user interaction, go wth SVG. Graphical user interfaces on the web are an especially delicious application for SVG.
As a final note, Matti and Samuli identify a gap that HTML 5 needs to fill: it would be great if you could go the other direction and turn an SVG image into it's rendered pixels to be passed to the Canvas tag, basically a toDataURL for SVG that can be passed into Canvas's fromDataURL.
ChemDoodle Web Components are pure javascript objects derived from ChemDoodle™ to solve common chemistry related tasks on the web. These components are powerful, fully customizable, easy to implement, and are free under the open source GPL license.
The page shows example usage of the components. To use the 3D Rotator component, for example, you just provide some JavaScript to configure it:
We usually post these on Friday, but who says a little fun on Monday is wrong? Paul Brunt has put together a nifty game using the Canvas tag. It's pretty impressive. He is also using Chrome Frame to have the game work on IE as well.
Content aware image resizing is a nifty technique where you can make an image smaller by literally understanding the content better and remapping it.
Stéphane Roucheray has put together a fancy demo (Firefox 3.5 only) that uses JavaScript and the Canvas tag plus createImageData to do all of this in the browser versus C++:
For this demo, a sub part of the Content Aware Image Resizing algorithm has been implemented. The width of the image can be reduced interactively without modifying its height. This implementation uses seam carving to re-size the image, subtracting the less visible vertical lines. It is a four step iterative algorithm. One iteration is one pixel width re-size. First an image is loaded into the Canvas context and then the iteration starts :
A grayscale version of the image has to be calculated
The edges of the image (Sobel convolution is used in our case) and its energy matrix is computed
The seam of least energy (1 pixel vertical line from the bottom to the top of the energy matrix) is detected
Then the pixel of the detected seam is removed from the original image and the result is re-injected as a source image to step 1
Each of the previous steps stores a whole matrix of data at the source image size. While these matrices are not all images but actually artifacts of the algorithm, storing them in an ImageData object is more convenient than using simple Arrays. This is why the createImageData method of the Canvas context is used. One of the benefits of this process is to allow showing the intermediate computations made under the hood.
As Chris Blizzard mentions in the blog post, this opens up lots of interesting possibilities:
This demo shows that’s possible to do more intelligent image resizing than just flattening an image’s pixels with CSS. Having computational and image manipulation capabilities directly in the browser opens up a new range of possibilities of how image data can be displayed to users. This is only one small demonstration of that.
The infamous excanvas has had a Silverlight bridge for some time. It is faster, yet has some artifacts and most people stick with good ole VML.
David Anson has put his hat in the ring by creating a new prototype canvas implementation in Silverlight.
Thanks to Silverlight's HTML Bridge, I had no trouble creating a Silverlight object that looks just like a <canvas> to JavaScript code running on a web page. So similar, in fact, that I'm able to run some pretty cool sample applications on my own <canvas> simply by tweaking the HTML to instantiate a Silverlight <canvas> instead of the browser's <canvas>. And as a nice side effect, Internet Explorer "magically" gains support for the
I did not attempt to implement the complete canvas specification. Instead, I implemented just enough to support the first 5 (of 6 total) Mozilla sample pages as well as the handful of applications shown above. Specifically, I've implemented everything that's not in italics in the feature list at the beginning of this post. Thinking about what it would take to add the stuff that's not implemented: text and pixel-level manipulation are both directly supported by Silverlight and should be pretty easy. Shadows seem like a natural fit for Silverlight's pixel shader support (though I haven't played around with it yet). All that's left is layer compositing, which does worry me just a little... I haven't thought about it much, but this seems like another job for WriteableBitmap, perhaps.
David gets a ton of the examples going though, and I am still hopeful that someone will continue work on this kind of shim to make a fast implementation. I need to go off and test Bespin.
