CodeDread Blog » SVG

SVG/Canvas Marketshare: July 2010

Jeff — Mon, 16 Aug 2010 03:18:31 +0000

SVGI’ve updated my marketshare spreadsheet for July 2010 charting the percentage of web users who can view SVG and Canvas: 41.82%

Note that this number is lower than last month’s because I could not include hitslink.com stats (they’ve put their stats behind a pay-wall now). If anyone knows of a better source of stats, let me know.

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.

IE9: No longer failing

Jeff — Thu, 24 Jun 2010 16:24:26 +0000

[clipart]Ok, after getting IE9 preview 3 installed last night, I was able to update my SVG scorechart. I’m pleased to say that I would now unequivocally classify IE9 as a browser that supports SVG. Supporting gradients, patterns, masking, clipping and more actually gained them quite a few points.

I’m also pleased to see that they support conditional processing (the <switch> element) so you can see at a rough glance what feature strings they claim to support by accessing this page I made years ago. Not a bad feature set for first time out! Kudos to the IE team!

And they support <canvas> too!

In my brief look at IE9 while running through the SVG tests, I would say their biggest areas to improve on before final release are text (especially text selection) and DOM. Though Alexis assures me that they do pass quite a number of SVG torture tests.

Hey, now that we have all major browsers supporting basic SVG rendering, it’s really time to ramp up the effort on SVG Torture Tests to ensure DOM coverage and corner cases. We are looking for someone to lead this activity in the SVG Interest Group.

Oh, and I would love to have SVG-edit working in IE9.

SVG Marketshare: May 2010

Jeff — Mon, 07 Jun 2010 05:46:05 +0000

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

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 shim, so this is really a worst-case number.

SVG Marketshare: April 2010

Jeff — Thu, 06 May 2010 19:12:56 +0000

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

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 shim, 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.

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
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

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.

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
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

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

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!

SVG-edit: One Year Old

Jeff — Sat, 06 Feb 2010 16:49:41 +0000

[clipart]One year ago today, Narendra Sisodiya started a tiny project called SVG-edit, with the very first check-in. He was trying to build a white-boarding application that could be used to facilitate online education.

Wow.

My kids couldn’t even talk at the age of one! Slackers…

It’s pretty amazing to think that this:

Can turn into this:

over the course of just one year, built in a lot of people’s spare time – but here we are!

I can’t wait to see what SVG-edit looks like on its 2nd birthday!

SVG 2.0 Wishlist

Jeff — Fri, 29 Jan 2010 13:20:31 +0000

[clipart]Robin Berjon posted about what his SVG 2.0 Wishlist would be. I think he used the hatchet a little too much, so I thought I’d give some feedback. Since he doesn’t support comments (boo!) here we go.

Chopping defs

This was probably my biggest annoyance/concern since, to my knowledge, the <defs> elements causes zero problems. Why would <head> or <g style=”display:none”> be preferable to <defs>? The defs elements provides semantics to a SVG document. Specifically, it acts like Flash IDE’s “stage”, where graphical editors can store and find the re-usable elements in a drawing. I don’t see any benefit to getting rid of <defs> nor do I see a problem that it causes. Why are you using <section> elements when <div> will do just fine on your blog, Robin?

Chopping SMIL

I think chopping SMIL at this point would be a bad idea, considering that all native SVG browsers are just coming online with this stuff now. Yes, SMIL is vastly underused, but frankly SMIL has not had a chance to prove itself – both in user agents and in graphical editors. I’d say now that it’s been (being) finally implemented, give SMIL a chance and drop it in SVG 3.0 (or whatever comes next) if it is still too under-used.

Your alternatives to SMIL are CSS3 Animations for simple cases (sounds good) and JS+DOM for complex cases. I disagree with the latter as the only way to animate complex SVG. I think that SMIL still has good uses there. Out of curiosity Robin, what do you think of SMIL Timesheets?

What we do need to solve is the DOM interface for SMIL. I agree baseVal and animVal are truly hated. In general, I think declarative animations make sense for SMIL, but I don’t know about the mixture of SMIL + DOM – that never quite made sense to me.

Maybe move SVG+SMIL out into its own SVG 2.0 Module and see how it fares and provide SVG DOM Core 2.0 that’s leaner, meaner and leaves out the SMIL?

Attributes and CSS Properties

What’s the migration strategy? If the SVG 2.0-capable browser encounters an attribute that was present in SVG 1.1 and not present in 2.0 – what should it do? Ignore? <circle fill=”blue” /> becomes black?

Not all editors universally love inline style attributes (though the popular ones do). Inline style attributes are another layer of parsing, another micro-syntax for hand authors, and can actually bloat the markup – unless you have more than 3 presentational attributes

I think removing the CSS properties as attributes will actually end up confusing authors further (what? i can set the radius of the circle using XML but not the stroke-width?). I think the decision to make presentational attributes was a conscious one based on the fact that SVG is such a visual language.

I guess I don’t have a better solution for CSS properties as XML attributes, because I admit that it is confusing as it stands, but I’m not convinced that simply removing them is the answer.

Slicing – not Chopping

[clipart]I hope that SVG 2.0 does become leaner. I just think that now that browsers are seemingly rallied around 1.1 Full and people are actually starting to use SVG that we need take a more cautious approach with changes. To me, carefully and iteratively shaving is a better approach than swinging a hacksaw and see what you end up with. Sorry to mix up so many blades in my analogies.

Here are some things I wouldn’t be upset about if they went away:

<symbol> – hardly needed if <use>-referenced elements could have a viewBox, I don’t think they add considerable semantics like defs does
<tref> – sure, I’ve never used it
<view> – agree with your comments
<audio>, <video> – agreed that HTML5’s versions are the future
<switch> – never lived up to its potential, unfortunately (though I guess this leaves server-side or JS as solutions for localization?
<font> and related – I agree with your idea to move it out of the ‘core’ spec. Put it into a module and see what happens with WOFF, etc
<foreignObject> – I agree that this shouldn’t be necessary to mix HTML in SVG. If inline HTML can somehow show up directly inline with SVG then we could also do away with <textArea> and others
version and baseProfile – I think I agree with you on this one, they could be dropped. But if this is done, we need a good way of marking features non-conforming and obsolete going forward. HTML5 still has spec text for the <font> element.

My Wishlist

I liked your “Better HTML Inlining” idea. I think it has merit.

You seem to be extremely focused on paring down the language so that implementers can reduce their “SVG code footprint”. While this is definitely a concern for me as well, I think your proposals for removal do not pay enough attention to authors, tool-makers and existing content.

Personally, I think the major focus for SVG 2.0 should be on one thing:

Making the DOM Suck Less

This alone could seriously help reduce the SVG code footprint in the long run (though I still don’t understand how browsers could easily obsolete their SVG 1.1 DOM code yet). I hope to see the SVG WG hosting a DOM Summit as mentioned by shepazu. I look forward to reading/seeing concrete examples and spec proposals from attendees there.

Once the SVG DOM is improved and we have interoperable implementations of SVG well-deployed around the web, then I would think about seeing what else needs to be cut in the next-next version of SVG.

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