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 1.5.0.4/Linux
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.
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.
Order of starting seemed to make little difference on my setup. FireFox 1.5.0.4, 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.
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”.
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....
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?
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,
On MacOSX 10.4.7 (PPC G4 1.6Ghz) with both Firefox 1.5.0.4 and Camino 1.0 I get consistently 2.5 seconds on canvas and 10 seconds on SVG, no matter who’s started first.
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.
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 1.5.0.4, XP Pro, 2.8GHz, 1G RAM, ATI X800GTO)
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
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.
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.
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.
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.
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.
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.
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.
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]...
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.