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.
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.
I get:
Firefox 1.5.0.4, WinXP SP2: SVG 1.763s, Canvas 1.482s;
Opera 9 build 8501, WinXP SP2: SVG 1.492s, Canvas 1.231s
on Win2K
when Canvas runs first:
Firefox 1.5.0.4
svg: 3.703 seconds / canvas: 16.656 seconds
Opera 9.0:
svg: 2.734 seconds / canvas: 9.594 seconds
when SVG runs first:
Firefox 1.5.0.4
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)
Firefox 1.5.0.4
svg: 1.796 seconds / canvas: 1.86 seconds
Opera 9.0:
svg: 1.672 seconds / canvas: 1.937 seconds
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.
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.
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)
Camino 1.0.2 on a 1.33 GHz Powerbook:
SVG 9.231 secs Canvas 2.803 secs
Very odd
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”.
Machine: MacBook Pro 15", Intel Core Duo, 2 GHz, ATI RadeonX1600, Firefox 1.5.0.4, OSX 10.4.7.
SVG: 4.508
Canvas: 1.509
Machine: Intel(R) Pentium 4 CPU 3.00GHz, Intel 910GL Graphics Controller, Firefox 1.5.0.4, 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....
Ubuntu Dapper, FF 1.5.0.4, 3GHz P4
SVG first: SVG 1.9561, Canvas 12.803
Canvas first: SVG 1.617, Canvas 13.1
Opera 9.01 here, on Windows XP at an Athlon XP 3000+:
Order doesn’t matter much.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Every time I run the tests, regardless of order, I get 2.0xx seconds for SVG and 3.5-4 seconds for canvas.
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.
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.
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:1.8.0.4) Gecko/20060620 Firefox/1.5.0.4 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?
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
Why?
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.
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
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.
I tried with IE6 running Adobe’s SVG plugin under Wine :-)
Unfortunately it crashed into the wall (AKA application/xhtml+xml
).
Firefox 1.5.0.4 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.
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)
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.
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
Firefox 1.5.0.4
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
Firefox 1.5.0.4
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
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.
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.
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
Firefox 1.5.0.1 under fedora core 5 seems to produce MUCH greater variance than most people are seeing:
SVG FIRST
SVG: Elapsed: 1.791 seconds
Canvas: Elapsed: 9.498 seconds
CANVAS FIRST
SVG: Elapsed: 1.814 seconds
Canvas: Elapsed: 9.074 seconds
I got you beat, masukomi:
SVG FIRST
SVG Elapsed: 1.199 seconds
Canvas Elapsed: 12.244 seconds
CANVAS FIRST
SVG Elapsed: 1.199 seconds
Canvass Elapsed: 12.244 seconds
FF 1.5.0.4
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
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 xdraw.org). Sluggish performance in Firefox on the Mac, zippy on Windows.
Mind you, until one actually reads the Mozilla code, this is all just conjecture...
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.
Canvas
Elapsed: 17.502 seconds
SVG
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.
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.
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
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)
SVG is faster for me
Elapsed: 1.407 seconds
Canvas
Elapsed: 1.544 seconds
1.032 -> SVG, 1.031 --> Canvas,
1.031 -> Canvas, 1.041 --> SVG
4×2.3, etc...
Firefox 2.0, Winblows XP