CodeDread Blog » canvas

SVG/Canvas Marketshare: Nov 2010

Jeff — Tue, 21 Dec 2010 17:31:48 +0000

I’ve updated my marketshare spreadsheet for Nov 2010 charting the percentage of web users who can view SVG and Canvas: 44.57%

I’m also tracking what percentage of web users can see SVG in an <img> tag: 18.41%

SVG/Canvas Marketshare: Aug 2010

Jeff — Sun, 12 Sep 2010 16:33:21 +0000

I’ve updated my marketshare spreadsheet for Aug 2010 charting the percentage of web users who can view SVG and Canvas: 41.08%

Still looking for more stats sites – it seems that W3Counter is also not reliable (their public web stats for August were still not generated as of Sep 12th).

SVG/Canvas Marketshare: June 2010

Jeff — Sun, 11 Jul 2010 06:47:33 +0000

[clipart]I’ve updated my marketshare spreadsheet for June 2010 charting the percentage of web users who can view SVG and Canvas: 41.49%

Note that I added “Canvas” back into the title of these blog posts, now that it is public that IE9 is supporting the HTML5 <canvas> element. I’ve also added SVG-as-an-image (usable inside <img> or as a CSS background-image), since that’s something that seems likely to be supported soon by all browsers (Firefox 4, IE9).

P.S. This figure does not take into account any user that has a SVG plugin installed or authors who have used the excellent SVG Web or excanvas shims, so this is really a worst-case number.

SVG/Canvas Marketshare: Mar 2010

Jeff — Mon, 05 Apr 2010 01:16:42 +0000

[clipart]I’ve updated my marketshare spreadsheet for March 2010 charting the percentage of web users who can view SVG/Canvas: 39.99%

Link to spreadsheet

P.S. I should mention that this figure does not take into account any user that has a SVG plugin installed or authors who have used the excellent SVG Web or ExplorerCanvas shims, so this is really a worst-case number.

To And Fro

Jeff — Wed, 31 Mar 2010 13:45:23 +0000

[clipart]Issue 70 has been open for awhile now. In fact it’s one of just a handful of two-digit bugs left in SVG-edit. Now that all browsers have heralded support for SVG into the future, one might argue that the need for this bug will evaporate in a couple years. However, one would be wrong. First, there are lots of mobile browsers out there. Second, in some cases it could be easier to just tell the browser how to draw a collection of dots rather than mathematical instructions (think thumbnails). So how to solve it?

One thought that occurred to me is if I can shove the SVG into a HTML5 Canvas element, I can then call toDataURI() on it to generate a PNG. Unfortunately only Opera seems to have experimented with loading SVG into a Canvas directly. Also, there are many effects that can be done in SVG that cannot be done in Canvas (filters, fonts, and more).

The Canvas2D API does mention that in the future, the svg:image element may support the CanvasElement DOM interface. I’m anticipating Microsoft to announce <canvas> support for IE9 later this year and probably to support this interface on svg:image elements. It’s one way they can innovate on the web standards front while they continue to catch up to other modern browsers.

This would be good, but why only the svg:image element? I’d argue that any element that contains some geometry could gain the toDataURI() method (particularly useful would be the <svg> element here).

Until such time as browsers all get in sync, there are other options. canvg is one such option and I’ve been dutifully raising bugs and writing teeny patches but there’s a long ways to go for a robust solution.

Ultimately this is another case of why am I doing something in script that all browsers already know how to do? You really have to think long-term in the web space, don’t you?

Other ideas?

Know The Beast

Jeff — Mon, 22 Mar 2010 01:07:09 +0000

[clipart]Cameron Adams decided to benchmark Flash, SVG, Canvas and HTML5 using a particle engine he created. Not surprising (to me anyway), the SVG scores were the worst of the bunch. This stands to reason: does each particle really need to be a DOM element? Nonetheless, I decided to see what I could do to make the SVG scores suck less. I thought I’d use it as an opportunity to also teach some techniques.

Update: Added some browser scores for Nov 2011

Particle Creation

Cameron initializes the particles this way:

	var domNode = document.createElementNS(SVG_NS, "circle");
	var benchmark = document.getElementById("benchmark");
	benchmark.appendChild(domNode);

	// Set initial position to middle of screen
	domNode.setAttribute("cx", x + PARTICLE_RADIUS);
	domNode.setAttribute("cy", y + PARTICLE_RADIUS);
	domNode.setAttribute("r", PARTICLE_RADIUS);

	// Set colour of element
	domNode.setAttribute("fill", COLORS[Math.floor(Math.random() * COLORS.length)]);

That is, he creates a svg:circle element, then appends it to the DOM, then modifies its attributes. Every time an attribute is changed in the DOM it has the potential to cause a layout/render change. Thus, it makes more sense (to me) to attach the circle to the DOM only after you’re done initializing the element (i.e. after all the setAttribute calls).

This doesn’t affect the frame-rate, since creation only happens at the beginning, but it might affect the startup time of the animation so I thought I’d drop it in this post.

DOM Animation – the Naive Approach

Next, he has a function that is called as fast as possible to animate the particles. The animate function does a simple loop over all particles and calls a draw() function. The particle’s draw function does this:

		// lots of other JS code here
		domNode.setAttribute("cx", nextX + PARTICLE_RADIUS);
		domNode.setAttribute("cy", nextY + PARTICLE_RADIUS);

The problem with this again is that each DOM call can cause a re-render. This means if you have 500 particles, there are 1000 DOM calls affecting the rendering with every call to animate(). Depending on how stupid the browser is, this could be expensive.

Click here to try the original demo

Original Results

Browser	Frame Rate
Firefox 3.6 (OSX)	1.75 fps
Firefox 3.7 Nightly (OSX)	1.9 fps
Firefox 8 Beta (OSX)	3.8 fps
Opera 10.10 (OSX)	12.5 fps
Opera 10.50 (OSX)	14.5 fps
IE9 Preview 1 (Win7 VM)	28 fps
Safari 4.0.5 (OSX)	32 fps
Chrome 5 Nightly (OSX)	40 fps
Chromium 17 Nightly (OSX)	55 fps

Suspension

My first attempt was to use suspendRedraw() and unsuspendRedraw() around the for-loop that calls particle.draw(). This is the SVG-recommended way to do a bunch of operations ‘off-screen’ and then have the results updated in one-shot. This did have an effect on Firefox’s frame rate.

But it didn’t really seem to affect WebKit’s performance at all. Looking at the WebKit source (svg/SVGSVGElement.cpp) it’s pretty easy to see why:

unsigned SVGSVGElement::suspendRedraw(unsigned /* maxWaitMilliseconds */)
{
    // FIXME: Implement me (see bug 11275)
    return 0;
}

Maybe WebKit will one day implement this and the technique will become more broadly useful. [Update Nov 2011: This has been implemented in WebKit]

Click here to try the demo that uses suspendRedraw

SuspendRedraw Results

Browser	Frame Rate
Firefox 3.6 (OSX)	3.2 fps
Firefox 3.7 Nightly (OSX)	3.4 fps
Firefox 8 Beta (OSX)	8 fps
Opera 10.10 (OSX)	8.2 fps
Opera 10.50 (OSX)	23.5 fps
IE9 Preview 1 (Win7 VM)	N/A
Safari 4.0.5 (OSX)	32 fps
Chrome 5 Nightly (OSX)	40 fps
Chromium 17 Nightly (OSX)	45 fps

NOTE: IE9 Preview 1 has not implemented suspendRedraw() and the demo does not run.

Manually Doing Off-Screen Rendering

I then went and did something crazy.

I added a svg:g (group) element to the particle test, added all the particles to it. Then with each call to render, I remove the <g> from the DOM, call all the particle draw() functions, then re-add the <g> to the DOM.

This had a dramatic effect on Firefox’s performance, but it seemed to slow down Safari and Opera. Not sure why that would be, but I guess they have much more sensible ways of updating the rendered state of the DOM than Firefox so that removing and adding an element to the DOM becomes more expensive.

Click here to try the demo with manual off-screen rendering

Manual Offscreening Results

Browser	Frame Rate
Safari 4.0.5 (OSX)	12.75 fps
Opera 10.10 (OSX)	14 fps
Firefox 3.6 (OSX)	21.5 fps
Firefox 3.7 Nightly (OSX)	21.5 fps
Opera 10.50 (OSX)	23.5 fps
IE9 Preview 1 (Win7 VM)	25 fps
Chrome 5 Nightly (OSX)	26.5 fps
Firefox 8 Beta (OSX)	37 fps
Chromium 17 Nightly (OSX)	49 fps

Conclusion

This blog post is really just an attempt to share the knowledge about some of the challenges in using SVG for high-performance demos. Basically don’t change the live DOM if you can avoid it.

Note that I still stand by my original statement that SVG is not the right technology for particle effects unless you need mouse interactivity. This type of demo is much more suitable for HTML5′s <canvas> element. Let’s hope IE9 also implements a GPU-accelerated version of this element too!

Canvas/SVG Marketshare: Feb 2010

Jeff — Fri, 05 Mar 2010 01:44:03 +0000

[clipart]I’ve updated my marketshare spreadsheet for February 2010 charting the percentage of web users who can view SVG/Canvas: 37.92%

Link to spreadsheet

Canvas/SVG Marketshare: Jan 2010

Jeff — Tue, 02 Feb 2010 21:24:00 +0000

[clipart]I’ve updated my marketshare spreadsheet for January 2010 charting the percentage of web users who can view SVG/Canvas: 36.86%

Spreadsheet

SVG Marketshare: Dec 2009

Jeff — Tue, 26 Jan 2010 13:25:53 +0000

[clipart]I decided to start publishing the percentage of web users who can view SVG/Canvas, starting with December 2009: 35.62%

Spreadsheet