Tuesday, June 24th, 2008

Rendering performance in Canvas compared to SVG and VML

Category: Canvas, Performance

Just after I posted about Ernest’s canvas experiment with photos he put something else up that tests the performance of rendering polygons with Canvas compared to other techniques.

The demo lets you run a live test, and view saved tests, comparing the Google Maps interface, which “currently draws polygons using VML for Internet Explorer, SVG for Firefox and image retrieval for Safari and Firefox linux.”

Canvas Rendering Compare

At first the results were surprising. The canvas version was magnitudes faster. However, then they worked out that the live Google Maps version is actually doing a lot more than just drawing the polygons, that being said, a commenter had a valid point:

If we analyze the rendering time of the markup alone, both SVG and VML are not necessarily slower than canvas and canvas+excanvas.js. So the difference in performance is due to the implementation of polygons before the markup is output which the canvas implementation is skipping.

That doesn’t make the experiment invalid. You didn’t show that Canvas is faster than SVG or VML.
But you did show that it’s possible to get much better polygon performance than the current API using a more direct to the metal approach – with whatever rendering engine. And people are crying out for faster polygons.

Posted by Dion Almaer at 8:59 am

3.7 rating from 31 votes


Comments feed TrackBack URI

This was a huge factor for an application I wrote about a year ago that plots graphs. SVG was way to slow to even consider. Which is sad cause the dojo charting stack is much nicer than anything I had time to write.


FYI this won’t run in IE… I left NASA before I had time to implement iecanvas. And really, screw IE anyway the could have followed standards.

Comment by mojave — June 24, 2008

Really cool. Canvas definitely grabs one’s attention seeing these demo’s. This guy is clearly an expert.

Where can we get a great canvas book? Will someone write one??

minor article nit: “magnitudes” is not accurate. an order of magnitude is 10x… what is shown is a nice 3x-4x improvement

Comment by holts — June 24, 2008

I’ve been using Canvas quite a bit. I use flot (jQuery charting) and my own pie charts.

As more people use Canvas, IE looks worse and worse. Yes, iecanvase works fine, but it’s slow. Makes ie8 feel like a pig.

People should yell at Microsoft to get native Canvas in. (I’ve done my part, I slammed IE’s stance on twitter without realizing I had Chris Wilson following me. He graciously asked for examples of how Canvas is becoming popular, so I think he’s open to the ida of getting it in there.

Can someone tell me why Microsoft has an excuse for not supporting things that are in all 3 of the other major browsers? In my opinion, if you see that you’re the only browser that’s missing something, you just DO it. Especially if you have Microsoft’s resources.

Comment by Nosredna — June 24, 2008

plus VML is M$ proprietary crap, which is illustrated as the only error on my map pages :-)

Comment by BillyG123 — June 24, 2008

Yeah, I’ve fallen in love with Canvas recently, and I actually think it’s great that IE doesn’t support it — it shows those users a really cool thing that they’re missing (and that they should switch!).

Comment by richtaur — June 24, 2008

Yes, canvas would be the way to go if we could magically uninstall each and every IE installation worldwide. For now, between 70 and 80 percent of the visits to our websites are done with IE. 40% percent is still IE 6..

Comment by jax — June 25, 2008

So aside from performance.. what’s the tipping point between server provided (GDI) and Canvas driven rendering?

Performance aside, it’s a application design choice. One thing for certain: the lines of code to build an intricate design may in fact be bigger, than a PNG download.

So there’s a lot of sides to this coin.

Comment by ibolmo — June 25, 2008

Canvas definately blows the pants off of SVG/VML, and it should. Canvas is a procedural immediate mode API ala OpenGL/DirectX/QuickDraw/GDI, and SVG/VML are retained mode APIs. The native code path between a call to stroke() or fillRect() vs inserting VML/SVG into the DOM is far shorter.

I’ve got one of the more intensive Canvas code bases (http://timepedia.org/chronoscope/demo/advanced/), and my own tests with VML/SVG showed it to be unusable for highly interactive rendering. I had to dump excanvas in favor of using a Flash-emulated WHATWG Canvas (http://timepedia.blogspot.com/2008/01/chronoscope-demo-in-flash-whatwg-canvas.html) for IE6 to obtain needed performance. IE6 has been the bane of my existence, and I wish I could sue Microsoft for lost productivity needing to add special support for their browser.

I’ve been arguing for along time that Google Gears should incorporate an implementation of WHATWG Canvas, but one that includes transformed text rendering, as well as image processing (i.e. convolution kernels, etc) Having one high speed, cross-browser implementation in Gears would be very nice.

Comment by cromwellian — June 25, 2008

Canvas is not without its problems, the biggest one being the current lack of text support. Although that recently went into the draft specification, it’d be a while before any browser supports it.

another problem is that canvas describes the whole canvas, instead of a group of objects, like svg. in order to transform a part of the drawing, you’d have to redraw the whole thing. from what I understand, svg canvases are a bunch of objects that can be freely transformed.

Comment by urandom — June 25, 2008

I was the anonymous commenter on Ernest’s test page. (Ernest, feel free to attribute the comment. :-) And Ajaxians, why can’t I change my display name to my real name instead of my initials without re-registering?!?)

The real point of interest in the Google Maps performance test turned out not to be Canvas performance, but rather optimizing a path through an API.

If you draw multiple polygons in the Google Maps API, each polygon is a separate object, requiring a trip through the JavaScript API for each one, with various data conversions happening along the way.

Consider the polygons required to draw the 50 states, or just a more detailed representation of Alaska as in the example. It’s a lot of polygons, with all that overhead for each one.

Ernest’s Canvas code bypasses this by drawing all of the polygons into a single Canvas object. The Maps API can then treat this as a single overlay, instead of one overlay per polygon. This results in a huge saving inside the Maps API.

Alas, this code won’t work for mapplets, but it could be quite nice for Maps API applications that use a lot of polygons.

Of course, you can get even better polygon performance in Google Maps by creating a tile layer overlay, but that is more work and isn’t very good for dynamically generated polygons or polygon fill colors.

Comment by MG — June 25, 2008

I wrote up a bit on a rendering performance comparison between Canvas and SVG here: http://www.borismus.com/canvas-vs-svg-performance/

Great site!

Comment by borismus — January 21, 2009

@farisalom – not sure what you mean by ‘same platform’. I made a little update in the text with a conclusion. The link of the comment above is also a good reference.

Comment by ernestdelgado — February 21, 2009

Leave a comment

You must be logged in to post a comment.