CODEWITHSUNDEEP
performancesvgvisualization
peteorpeter
peteorpeter

Reputation: 4097

Does reusing symbols improve SVG performance?

Assuming a relatively modern, SVG-supporting desktop browser and an SVG consisting of hundreds of similar, simple nodes:

  1. The document could be set up as many individual shape elements (<circle>, <line>, etc.) with their own attributes defined.
  2. The document could be set up as a few <symbol> elements and many individual <use> instances that place them and size them appropriately (W3 spec).

I understand the semantic and code-maintenance reasons to use <symbols>/<use>, but I'm not concerned with those now, I'm strictly trying to optimize rendering, transformation and DOM update performance. I could see <symbol> working similar to reusing sprites in Flash, conserving memory and being generally a good practice. However, I'd be surprised if browser vendors have been thinking this way (and this isn't really the intent of the feature).

Edit: I am not expecting the base symbols to be changed or added to over the life-cycle of the SVG, only the instance locations, sizes, etc

Upvotes: 29

Views: 11293

Answers (3)

F Lekschas
F Lekschas

Reputation: 12800

Rohit Kalkur compared rendering speed of the creation of 5000 SVG symbols using use against directly creating the SVG symbol's shapes, see here. It turns out that rendering SVG shapes using use was almost 50% slower. He reasons that:

The use element takes nodes from within the SVG document, and duplicates them in a non-exposed DOM

Given this, I assume that using SVG symbols is at best as performant as manually creating the symbolss shape.

Upvotes: 17

Erik Dahlstr&#246;m
Erik Dahlstr&#246;m

Reputation: 60976

I would advise you to not nest <use> elements deeply. That is known to cause slowdowns in most browsers, see here and here.

In the general case though it should be fast, at least as long as the template itself isn't changed much (since if you do then each of the instances need to be updated too, and each of them can differ from the rest due to CSS inheritance).

Between <svg> and <symbol> there isn't that big of a difference on a functional level, they both allow you to define a coordinate system (via the 'viewBox' attribute). A <g> element doesn't let you do that. Note that <symbol> elements are invisible unless referenced by a <use>, whereas <svg> and <g> are both visible per default. However, in most cases it's advisable to make the template be a child of a <defs> element.

Upvotes: 9

Robert Longson
Robert Longson

Reputation: 124089

If you change the contents of a g or svg element then a UI can look at the area the old contents were drawn in and where the update will be drawn to and simply redraw those two areas, even redraw only once if they are the same e.g. changing the colour of a shape.

If you update the contents of a symbol then all the instances must be redrawn. It's harder to do that by calculating for each instance where the old and new parts to redraw are as the areas may be affected by transforms and simpler to just redraw all parts of all instances. Some browsers may do the former and some the latter.

In either case, a UI must at a minimum track the changes in the symbol and propagate those changes to all the instances. That's more than likely to have some overhead.

Of course, if you're just moving individual symbol instances and the contents are static then no tracking is required and performance is likely to be similar.

Upvotes: 3

Related Questions