It’s just data

SVG vs Canvas

I ported my incremental Penrose Tiling from SVG to Canvas, and am at a loss to explain the difference in performance.  If you have an SVG and Canvas aware browser, give this a whirl and tell me what you see.

The issue seems to have something to do with setTimeout (both run virtually instantaneously with this small sample — it is when the image is rendered incrementally that the inexplicable slowdown occurs).  What is even more puzzling is that the difference in timings is about the same on both Firefox 1.5 and Opera 9.0.

Note: whichever is run second seems to get a minor boost from whatever initialization is already done, so be sure to refresh and try the tests in the other order before reporting results.

For me, t seems to be about ~0.2-0.3 seconds faster using <canvas> than SVG under Firefox

Posted by jgraham at

On FF 1.5/Mac, the canvas version is 3 seconds faster.  SVG has always been slow......

Posted by Paul Querna at

Very, very wierd.  On all four permutations of FF 1.5, Opera 9.0 and Ubuntu Dapper and Windows XP, I’m seeing around 2 seconds for SVG and 10 seconds for canvas.

Posted by Sam Ruby at

Sam, I get results similar to yours (1.5s vs. 12s) on FF and Ubuntu Dapper.

A data point might be that the results are identical both with my ThinkPad’s CPU at full 1.8GHz and at 800MHz.

Weird indeed.

Posted by Michele at

I get:

Firefox, WinXP SP2: SVG 1.763s, Canvas 1.482s;

Opera 9 build 8501, WinXP SP2: SVG 1.492s, Canvas 1.231s

Posted by Nick Fitzsimons at

Oh, forgot to mention, I did a few reloads and ran different tests first, and it didn’t really seem to make any difference.

Posted by Nick Fitzsimons at

on Win2K

when Canvas runs first:
  svg: 3.703 seconds / canvas: 16.656 seconds
Opera 9.0:
  svg: 2.734 seconds / canvas: 9.594 seconds

when SVG runs first:
  svg: 3.563 seconds / canvas: 16.5 seconds
Opera 9.0:
  svg: 2.828 seconds / canvas: 9.531 seconds

If I hide the window during drawing (by switching to another app), it’s much faster; the time is not accurate because I have to switch

(canvas runs first)
  svg: 1.796 seconds / canvas: 1.86 seconds
Opera 9.0:
  svg: 1.672 seconds / canvas: 1.937 seconds

Posted by jm at

Flock 0.7.1, Windows 2000 Pro, AMD Athlon 2Ghz approx
SVG 1.11  Canvas 2.454
SVG 1.203 Canvas 2.344
SVG 1.75  Canvas 3.484
SVG 1.312 Canvas 3.39

Posted by Anton Tagunov at

On my Opera 9.0 it doesn’t seem to work at all. I believe this is because it’s getting served and parsed as HTML (rather than XML) and the JavaScript compiler is getting upset about the <![CATA[  ]]> block.

I think the most painless solution would be to just put a “//” before the opening and closing parts of the CDATA construct, so that when parsed in HTML mode they’ll be commented out.

Posted by Martin Atkins at

On my Opera 9.0 it doesn’t seem to work at all. I believe this is because it’s getting served and parsed as HTML (rather than XML)

I was serving this file as application/xhtml+xml to all browsers that claim to support it.  Based on my read of the log files, it appears that you might be running some sort of anonymizing proxy which may strip out identifying headers.  Fair enough: I’ve just changed it so that this file will be served as application/xhtml+xml to all browsers.

Posted by Sam Ruby at

Maybe it’s your video card/drivers? SVG and Canvas might tickle different areas.

Posted by Chris Nokleberg at

Order of starting seemed to make little difference on my setup.  FireFox, Win XP Pro with all the latest updates, 3.2 GHz dual core P4,  256 MB ATI RADEON X600.  Timings were always roughly 1.5 secs for the SVG and 1.4 secs for the Canvas.

Posted by Doug Bitting at

Maybe it’s your video card/drivers? SVG and Canvas might tickle different areas.

My Ubuntu tests were run using:

ATI Technologies Inc M10 NT [FireGL Mobility T2] (rev 80)

My WinXP tests were run using:

nVidia Corporation NV6 [Vanta/Vanta LT] (rev 15)
Posted by Sam Ruby at

Camino 1.0.2 on a 1.33 GHz Powerbook:

SVG 9.231 secs Canvas 2.803 secs

Very odd

Posted by John Wilson at

On this knackered old Pentium 2 box I’m being forced to use at the moment, the SVG seems to consistently come in at about 3.5s and the canvas about 4s. This is in Opera 9 under Windows 2000. I’m a little bemused that Opera’s SVG on my 350MHz Pentium 2 has managed to beat Camino running on a 1.33GHz Powerbook, and Opera’s canvas support seems to beat Firefox by quite a wide margin under Windows.

As for my browser, while it’s true that it’s not saying “Hey, I’m Opera!” in the User-Agent header, it is saying “Accept: application/xhtml+xml”.

Posted by Martin Atkins at

Machine: MacBook Pro 15", Intel Core Duo, 2 GHz, ATI RadeonX1600, Firefox, OSX 10.4.7.
SVG: 4.508
Canvas: 1.509

Machine: Intel(R) Pentium 4 CPU 3.00GHz, Intel 910GL Graphics Controller, Firefox, Linux/RHEL 4.
SVG: 1.897
Canvas: 1.837

Extremely OS specific results. I would guess that the Canvas is somehow being hardware accelerated on the Mac, and the SVG is rendering purely in software....

Posted by Paul Querna at

Ubuntu Dapper, FF, 3GHz P4

SVG first: SVG 1.9561, Canvas 12.803
Canvas first: SVG 1.617, Canvas 13.1

Posted by Ken Kennedy at

Win XP SP 1, ATI Radeon 9600 - P4 2.6ghz
consistent, load order independent 1.9s for SVG and 2.1 for Canvas...

Posted by Claus Dahl at

WinXP tablet, FF1.5, various results, all (SVG and canvas) within 0.1s of 2s.

Posted by Phil Wilsom at

Opera 9.01 here, on Windows XP at an Athlon XP 3000+:

Order doesn’t matter much.

Posted by Rijk at

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060508 Firefox/

Every time I run the tests, regardless of order, I get 2.0xx seconds for SVG and 3.5-4 seconds for canvas.

Posted by Scott Johnson at

On all four permutations of FF 1.5, Opera 9.0 and Ubuntu Dapper and Windows XP, I’m seeing around 2 seconds for SVG and 10 seconds for canvas.

So am I; though on Slackware 10.2.

Posted by Aristotle Pagaltzis at

Firefox 1.5 on a (slow) FreeBSD 6.1 box results in times of 4.863s for SVG, and 12.966 for canvas. The time’s pretty consistent across refreshes.

And as an extra bonus, Blogline’s Atom support has just regressed.

Posted by Keith Gaughan at

I get a consistent 1.7-ish for SVG and 2.4-ish for canvas.  I’m running Flock on Windows 2000 on a beat up Centrino 1600MHz.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20060620 Firefox/ Flock/0.7.1

Also, it looks like the canvas one has been rotated by one fifth anticlockwise, but that’s probably not what you meant when you asked what we could see :)

Does it work in VML with any of the Explorer canvas adapters?

Posted by Tom Carden at

As an alternative datapoint, I tried on a linux trunk build of Firefox (different machine) where the SVG doesn’t draw at all (known bug) but the script does run and I get about 1.2s for SVG and about 1.9 for canvas,

Posted by jgraham at

On MacOSX 10.4.7 (PPC G4 1.6Ghz) with both Firefox and Camino 1.0 I get consistently 2.5 seconds on canvas and 10 seconds on SVG, no matter who’s started first.

Posted by Stefano Mazzocchi at

Running the tests a number of times produces inconsistent results for me, using Opera 9 on Windows XP SP2 (1G RAM, ATI Mobility Radeon 9600).

In the first round of tests all the times were around 1.5 seconds (+/- 0.1) with SVG slightly faster than Canvas.

After browsing a few pages (reading blogs) I tried again and this time the mean was around 1.4 seconds (+/- 0.5) with Canvas now consistently faster.

Round three.  The mean time dropped to ~1.3 seconds (+0.4, -0.2).  Canvas had the fastest rendering time ~1.1 seconds and was consistently the fastest.  SVG rendering produced a couple of slow times ~1.7 seconds.

The variations test to test were generally greater than the differences between SVG and Canvas

My theory is that background OS activity (virus scanner, desktop search, Windows explorer, task manager, ...) is having an affect on the results.  Ideally, the tests should be run in an environment where these external factors are minimised.

Posted by Bill Donoghoe at

On several runs, I’m getting results anywhere between 1.35 and 1.6 seconds for both of them. Sometimes one is faster, sometimes the other; which one runs first doesn’t seem to matter on my system. (FF, XP Pro, 2.8GHz, 1G RAM, ATI X800GTO)

Posted by Luke Hutteman at

They’re pretty much the same for me, with canvas slightly faster under Opera and SVG slightly faster under Firefox. I’m running Ubuntu Dapper for AMD64 (X2), so Firefox is 64-bit and Opera is 32-bit.

With the results in form SVG/canvas:

Firefox: SVG first 1.242/1.315 and canvas first 1.226/1.364
Opera: SVG first 1.147/0.944 and canvas first 1.132/0.949

Posted by Porges at

Webkit build 15309, OS X 10.4.7 (PPC), 1.8Ghz PPC 970 (x2)

SVG: 1.853 seconds
Canvas: 1.594 seconds

Canvas:1.589 seconds
SVG: 1.922 seconds

Observation — Webkit’s Canvas implementation is doubtlessly quite optimized, seeing as how it’s the basis of Dashboard.

Posted by d.w. at

I tried with IE6 running Adobe’s SVG plugin under Wine :-)

Unfortunately it crashed into the wall (AKA application/xhtml+xml).

Posted by Porges at

Firefox on WinXP on P4 3GHz Hyperthread with 256MB Radeon X600

I get consistently between 1.1 and 1.2 seconds on both Canvas and SVG regardless of which I start first. 

One exception: If I shrink the browser window so that the two tests overlap, then Canvas runs 4x slower.  But only if the SVG has already run.  SVG runs in 1.1 sec regardless.

Posted by Kevin H at

hmmm strange. The results are not stable. I mean if you run the tests it changes each time.

For example right now, I had.
3.721s for SVG
2.233s for Canvas

(Camino 1.0.2, macbook Intel Core Duo, 2Ghz, 2Go RAM, OSX 10.4.7)

Posted by karl at

On fast machines, all the time is in the setTimeout call. So you get consistently 1.5 seconds for both tests.

I changed the setTimeout to a simple while (true) loop, and then the tests were too fast to measure precisely. Upping n to 4 gives me 0.7s for SVG and 0.5 for canvas. For n = 5 I get 3.6s for SVG and 2.3s for canvas.

So SVG is about 50% slower than canvas, which makes sense as canvas is fire and forget, while SVG builds a DOM.

Posted by Sjoerd Visscher at

I should have read your post better. I can imagine that SVG requires a redraw of the complete DOM at every setTimeout, because you can draw below an existing thing too. Or at least you need some calculations to be sure you don’t need to redraw everything.

Posted by Sjoerd Visscher at

In Opera 9.01 build 8518; SVG: 2.228 seconds, Canvas: 1.979 seconds. SVG had smoother antialiasing of the diagonal lines and overall looked better, but Canvas was definately a bit faster.

Posted by Asbjørn Ulsberg at

All figures are the average of four runs.  To summarise, Canvas was significantly faster everywhere except Opera on the PowerBook.  In some cases there was a slight improvement if run second, others it made no difference.  Strangest was Canvas on Camino/PowerBook with was 2.5x slower when run second. 

Machine: 1.5 GHz PowerBook OSX 10.3.9
Canvas first: Canvas - 2.840 SVG - 13.724
SVG first: SVG - 13.773 Canvas - 2.787

Camino 1.0
Canvas first: Canvas - 3.040 SVG - 8.960
SVG first: SVG - 8.940 Canvas - 7.401

Opera 9
Canvas first: Canvas - 2.116 SVG - 1.712
SVG first: SVG - 1.801 Canvas - 2.125

Machine: Dual 1.8 GHz PowerPC G5 OSX 10.3.9
Canvas first: Canvas - 1.697 SVG - 4.344
SVG first: SVG - 4.412 Canvas - 1.566

Camino 1.0
Canvas first: Canvas - 1.621 SVG - 3.674
SVG first: SVG - 3.651 Canvas - 1.546

Opera 9
Canvas first: Canvas - 1.155 SVG - 1.382
SVG first: SVG - 1.390 Canvas - 1.123

Posted by Michael C. Harris at

So SVG is about 50% slower than canvas, which makes sense as canvas is fire and forget, while SVG builds a DOM.

To be honest, that’s the results I expected for this test.  This image, as implemented, is entirely dynamic, and therefore is playing to canvas’s strengths.  On the other hand, the inline static images that I have been placing on my entries would probably do better with SVG: after all the DOM’s already been parsed, now a graphics engine simply needs to take as input a number of declarative statements which may present a few opportunities for optimization.  With inline canvas, a parsed DOM contains only minimal information, and the real fun starts after you have parsed the JavaScript, and you pretty much are at the mercy of the coder.

What I didn’t expect was for Canvas to show any appreciable time with n=3, excluding the explicit and intentional time delays, on either of my two different machines, running two different operating systems, and with two different browsers.

Posted by Sam Ruby at

I did the same mods as Sjoerd Visscher (AFAIK), and here’s my results.

n = 5, svg/canvas order. Times shown are fairly representative, and the times were pretty consistent.

Firefox: SVG first 2.586/1.938, canvas first 2.444/2.081
Opera: SVG first: 1.884/0.737, canvas first: 2.204/0.712

Something of interest: On Firefox, the one run second ran faster than when it was run first, and the opposite was true with Opera.

Posted by Porges at

On Windows (1.8 Ghz P4):
FF: SVG 2.13 seconds, Canvas 2.64 seconds

On OS X (1.5 Ghz PowerPC G4):
FF: SVG 16.995 seconds, Canvas 2.9 seconds

Posted by Bob Aman at

Firefox under fedora core 5 seems to produce MUCH greater variance than most people are seeing:

SVG: Elapsed: 1.791 seconds
Canvas: Elapsed: 9.498 seconds

SVG:  Elapsed: 1.814 seconds
Canvas:  Elapsed: 9.074 seconds

Posted by masukomi at

I got you beat, masukomi:

SVG Elapsed: 1.199 seconds
Canvas Elapsed: 12.244 seconds

SVG Elapsed: 1.199 seconds
Canvass Elapsed: 12.244 seconds

Ubuntu Dapper

tim@tim-desktop:~$ uname -a
Linux tim-desktop 2.6.15-25-386 #1 PREEMPT Wed Jun 14 11:25:49 UTC 2006 i686 GNU/Linux

tim@tim-desktop:~$ cat /proc/cpuinfo
model name  : Intel(R) Pentium(R) 4 CPU 3.00GHz
cpu MHz  : 2992.850
cache size  : 1024 KB

tim@tim-desktop:~$ cat /proc/meminfo
MemTotal:  1035604 kB

Posted by Tim at

On my Windows XP machine, in Firefox 1.5, they’re both under 2 seconds. On my PowerBook G4 12", the Canvas is 2.9 seconds and the SVG is 13.2 seconds.

I fully attribute this to the hardware-accelerated GDI+ API being used for both Canvas and SVG on Windows Firefox, but the non-accelerated Cairo library being used for SVG on the Mac. Since the canvas API is lower-level than SVG, it would seem that the Mac Firefox developers found that OS X’s native drawing APIs (again, hardware-accelerated) could be used directly, hence the speed difference.

I’ve been seeing something quite similar with my little SVG drawing editor prototype (the one off the main page at Sluggish performance in Firefox on the Mac, zippy on Windows.

Mind you, until one actually reads the Mozilla code, this is all just conjecture...

Posted by Gavin Doughtie at

I am making a web site and tried the canvas thinking it will be faster than using multiple images. I was so wrong, the canvas is unusable on my computer.

Ubuntu breezy with firefox 1,5. Tried many times, always the same, here one of my result with canvas started first.

Elapsed: 17.502 seconds

Elapsed: 1.389 seconds

This should be fast, I make only lines! If only SVG was more supported, I think I will give it a try.

Posted by Riox at

On my Compaq Armada E500 running Ubuntu Dapper Drake

SVG: 2.672 seconds
Canvas: 9.164 seconds

Posted by Skinn3r at

W3C and the Overton window

Anne: a 2-minute Google search pulled up plenty of examples of people talking about, presenting on, and demonstrating SVG and canvas as if they were competing standards. [link]...

Excerpt from Comments on: W3C and the Overton window at

Nobody in the OpenSource community will want to hear this but if canvas is given an equal amount of devel effort/resources, then canvas will wind up killing SVG.

This is because it is an API NOT a specification/format. SVG is a beautiful specification with a great architecture. But it is slow. Canvas is ... well, it’s a hack. And guess what? It’s faster. In my tests, if I ran SVG first, then the Canvas operation was approx. 0.5 secs faster. If Canvas was first, then SVG was only about 0.15 faster.

I actually think this canvas back door (and ladies and gentlemen, this is a backdoor for browsers to do what they wish within an HTML panel) has a lot of potential.

Just my humble (outspoken) 0.02.

Posted by Geekkit at

Sam Ruby: SVG vs Canvas


Excerpt from at

Firefox 2.0/Mac OSX
PowerBook 12"

1st run:
SVG: 15.182 seconds
Canvas: 1.674 seconds

2nd run (reversed order):
Canvas: 2.433 seconds
SVG: 15.854 seconds

Posted by Folletto Malefico at

Firefox 3.0a9pre/Mac OSX
PowerBook 12"

1st run:
SVG: 2.418 seconds
Canvas: 62.333 seconds

2nd run (reversed order):
Canvas: 3.841 seconds
SVG: 2.84 seconds

(please note that on this Fx/Minefield alpha9pre the two boxes are overlapping)

Posted by Folletto Malefico at

OSX 10.4.10, Safari 2.0.4 (419.3) with nightly webkit engine SVN r27388 on a MacBook CoreDuo 1.83GHz:
SVG: 1.686 seconds/Canvas: 4.786 seconds
Canvas: 1.625 seconds/SVG: 1.589 seconds

Posted by Taavi Burns at

SVG is faster for me
Elapsed: 1.407 seconds

Elapsed: 1.544 seconds

Posted by Lance Dyas at

SVG: 2.689 seconds
Canvas: 2.774 seconds
Seamonkey-1.1.3 on a GNU/Linux with cairo+glitz+ati radeon 9600SE with yesterday opensource ati R300 drivers.

Posted by Popolon at

1.032 -> SVG, 1.031 --> Canvas,
1.031 -> Canvas, 1.041 --> SVG

4×2.3, etc...

Firefox 2.0, Winblows XP

Posted by Alyxandor at

I seem to get similar results with both, around 1.5 to 1.6 seconds with FF on WinXP.

Posted by LinuxDevil at

[from p3k] Sam Ruby: SVG vs Canvas


Excerpt from Delicious/network/chl at

IE9 Platform Preview 3 vs Chrome, Firefox, Opera, Safari

El día de ayer Microsoft lanzo una nueva versión de su IE9 Platform Preview. Varias de las características que llaman la atención de esta tercera entrega es el hecho de que  por fin han añadido soporte para <canvas> y han mejorado el soporte...

Excerpt from Logit42 at

IE9 Platform Preview 3 vs Chrome, Firefox, Opera, Safari

El día de ayer Microsoft lanzo una nueva versión de su IE9 Platform Preview. Varias de las características que llaman la atención de esta tercera entrega es el hecho de que  por fin han añadido soporte para <canvas> y han mejorado el soporte...

Excerpt from Logit42 at

Add your comment