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

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

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

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!

Disclaimer: The PlanetSVG website is still largely under construction, so please be gentle. Rob is working on a Drupal theme and we still have to plan out the overall flow of the site.

The first thing that struck me about the book was how thick it was – clocking in at over 600 pages. I had expected the book to be something I could take with me on the train to work each day. However, I prefer my vertebrae unfused, so I had to be happy with reading it at night. Maybe I should have investigated the eBook side of things…

The second thing I noticed: Every image in the book is full color. I don’t think I’ve ever seen a tech book do this, though I haven’t bought a tech book in a couple years. Usually there will be a few glossy pages in the middle of the book that show some color plates, but not every image. It’s a delightful surprise that must have been costly for O’Reilly. Yet the book is actually reasonably priced at $45 USD at Border’s – even cheaper on Amazon.

Ok, moving on to actual content… I’m actually only just a little over 1/3 of the way through the book and only have just begun reading the vector portions (beginning of Chapter 7). But here are some notes/thoughts so far:

• I like that Ms. Powers has made it a point that the contents of this book should be accessible to everyone – even those that have no budget for graphics tools. The focus of the book is that the web graphic artist must have fun. In fact, this is the title of the first chapter.
• Photography and photo manipulation are not big parts of my personal web experience, but it certainly is a wildly popular thing for a lot of people. Chapters 3 and 4 contain a lot of info about color profiles, curves/levels, image formats, photo editors, online photo galleries (including an introduction to Gallery2) and more.
• Some interesting bits about web design in Chapter 4. I actually did not realize that Opera comes with a ‘mobile emulator’. Now that I actually have a mobile data plan, I’ve begun to realize how important this is. For example, my site will not currently load up on my mobile browser, though I wouldn’t exactly call my mobile browser ‘modern’. My next theme redesign will definitely take into account the mobile web.
• Chapter 5 discusses lots of really interesting effects (3D and aqua buttons, reflections). By describing how these effects are generated using layers, gradients, blurs, and masks, one starts to visualize how these individual techniques can be combined to produce other effects seen on the web.
• Chapter 6 gives us a good introduction to some vector graphic formats, including a glimpse at VRML and X3D. I would have liked to learn a little bit more of X3D, maybe I should find some time to do that.

All in all, it’s been an interesting read. Now on to what I’m most interested in: Vectors. More to come…