Tuning SVG Performance in a Production Application

About Me

Rohit Kalkur

Software Engineer @ Social Tables

Twitter: @Rovolutionary

Github: rovolution

About Social Tables

• Based in Washington D.C.
• SaaS-based company with focus on event planning/management
• Venue Mapper - "AutoCAD for events"

• All objects in Venue Mapper are SVG!
• SVG allows us to:
  • preserve quality
  • make objects highly customizable
• Some objects consist of multiple SVGs

<svg>
    <circle class="table selected"  r="36" style="fill: rgb(255, 255, 255); stroke: rgb(0, 0, 0);"></circle>
    <g transform="translate(0, -36) rotate(180) rotate(0,0,-36)scale(1,1)">
	    <g style="overflow: visible"  class="selected">
	        <path transform="scale(2)" d="M -8,0 v 8 c 0,4 4,8 8,8 c 4,0 8,-4 8,-8 v -8 z" class="ring" style="stroke: none; fill: rgba(0, 0, 0, 0);" ></path> 
		<path d="M -8,0 v 8 c 0,4 4,8 8,8 c 4,0 8,-4 8,-8 v -8 z" class="ring"  style="stroke: rgb(107, 103, 103); fill: rgba(255, 255, 255, 0.2);"></path> 
	    </g>
    </g>
    <g  transform="translate(0, -36) rotate(180) rotate(30,0,-36)scale(1,1)">
	   <g style="overflow: visible"  class="selected">
	       <path transform="scale(2)" d="M -8,0 v 8 c 0,4 4,8 8,8 c 4,0 8,-4 8,-8 v -8 z" class="ring" style="stroke: none; fill: rgba(0, 0, 0, 0);" ></path> 
	       <path d="M -8,0 v 8 c 0,4 4,8 8,8 c 4,0 8,-4 8,-8 v -8 z" class="ring"  style="stroke: rgb(107, 103, 103); fill: rgba(255, 255, 255, 0.2);"></path> 
	   </g>
    </g>
</svg>

• Everyday we have hundreds of customers creating events
• It is critical to create the best user experience possible!

• Templates allow a user to click and drag to create a continous region of tables
• Very useful when trying to lay out tables for large venues such as a ballroom.

Templates

Let's try this with 150 tables!

• This slow performance is unnacceptable!!
• How can I improve this feature so that is performs seamlessly for hundreds of tables?

Why not try <use>?

• ​Since the SVG's for a chair and table are complex, create symbol's for each and create instances of them with <use>
• Maybe this will speed up the render time

Experiment Set-Up

• Create a simple web app that takes row/column numbers and generates row * column number of tables
• First generate tables with <use>, then without <use>
• Compare the rendering times and see if there is a performance boost

How to create a table with <use>?

<!-- Chair SVG Definition-->
<symbol id="chair">
    <g style="overflow: visible" class="selected">
        <path transform="scale(2)" d="M -8,0 v 8 c 0,4 4,8 8,8 c 4,0 8,-4 8,-8 v -8 z" class="ring" style="stroke: none; fill: rgba(0, 0, 0, 0);" ></path>
        <path d="M -8,0 v 8 c 0,4 4,8 8,8 c 4,0 8,-4 8,-8 v -8 z" class="ring"  style="stroke: rgb(107, 103, 103); fill: rgba(255, 255, 255, 0.2);"></path> 
    </g>
</symbol>

<!-- Table SVG Definition-->
<symbol id="table">
	<circle class="base-table selected" r="36" style="stroke: rgb(0, 0, 0); fill: rgb(255, 255, 255)"></circle>
        <use xlink:href="#chair" transform="translate(0, -36) rotate(180) rotate(0,0,-36) scale(1,1)"></use>
        <use xlink:href="#chair" transform="translate(0, -36) rotate(180) rotate(30,0,-36) scale(1,1)"></use>
	<use xlink:href="#chair" transform="translate(0, -36) rotate(180) rotate(60,0,-36) scale(1,1)"></use>
        <use xlink:href="#chair" transform="translate(0, -36) rotate(180) rotate(90,0,-36) scale(1,1)"></use>
</symbol>


<!-- Using the symbol to create 3 tables -->
<use xlink:href="#table" transform="translate(0, -36)"></use>
<use xlink:href="#table" transform="translate(0, -56)"></use>
<use xlink:href="#table" transform="translate(0, -76)"></use>

With <use> (5000 tables)

Without <use> (5000 tables)

• <use> is actually worse for performance!
• My hunch?
  • MDN definition: The use element takes nodes from within the SVG document, and duplicates them in a non-exposed DOM
  • The SVG nodes that make up a <use> tag still exist on the page
  • No real reduction in DOM elements

• Lets try another approach!
• But first, lets get a better understanding of the Venue Mapper core technology stack

Background: Knockout.js

• Venue Mapper is build with Knockout.js
• Knockout JS has a data structure called observable arrays, which can be referenced in HTML
• When an JS object is added to an observable array referenced with the keyword foreach, it will render a copy of the markup bound to that object.

Background: Knockout.js

var shapes = ko.observableArray();

var circle1 = {
    x: 30,
    y: 30,
    color: "red"
};
var circle2 = {
    x: 90,
    y: 90,
    color: "green"      
};

shapes.push(circle1);
shapes.push(circle2);

Background: Knockout.js

<svg>
    <!-- ko foreach: shapes() -->
        <circle r="40" stroke="black" data-bind="attr: {cx: x, cy: y, fill: color}" />
    <!-- /ko -->
</svg>

Background: Knockout.js

Background: Reflow

• Definition: Web browser process for re-calculating the positions/geometries of elements in the document.
• Reflowing an element can sometimes require reflowing its parent elements and any elements which follow it
• Very expensive!!!

Why are previews so slow?

• Each table preview is created as a JavaScript object and then appended to a Knockout observable array of "floorObjects"
• Once added to "floorObjects", the SVG representation of the table is appended to the DOM
• For each table preview appended to the DOM, a reflow cycle occurs...This is bad!!!

Background: Document Fragments

• Definition: Lightweight container for holding DOM nodes
• Used to append a large number of nodes to the DOM at once

/*
    Assuming that 'shapes' refers to the array of shape data in earlier slide
*/
var fragment = document.createDocumentFragment();

for(var i = 0; i < shapes.length; i++) {
    // Create 'circle' element
    var circle = document.createElementNS("http://www.w3.org/2000/svg", "circle");
    // Set attributes on circle
    circle.setAttribute("cx", shapes[i].x);
    circle.setAttribute("cy", shapes[i].y);
    circle.setAttribute("fill", shapes[i].color);
    // Append circle to fragment
    fragment.appendChild(circle);
}

// Append the single fragment to the SVG element
document.getElementByTagName("svg").appendChild(fragment);

Background: Document Fragments

How can we speed this up?

• Generate the markup for a single table preview by appending it to the observable array.
• Keep a reference to this preview DOM element by assigning it an id: "#template-preview"
• Style the element with this id to have "display: none"

var table = {
    numChairs: 12,
    color: "white",
    radius: 10
}

• Why do we need the markup for just a single table?
  • Certain properties of the table SVG (such as chairs, color, and radius) are dependant on the value of the corresponding JavaScript object
  • We need to append one of these objects to the floorObjects observable array in order to generate the correct table SVG

How can we speed this up?

1. Create a Document Fragment.
2. For each preview element to be created:
   • use cloneNode() on the #template-preview element to create a copy of the node
   • Set the x,y positional properties on this new node
   • Append new node to the document fragment

3. Append this document fragment to the SVG element

Did this work?

Can we do better?

Object Pool

• Create two JS arrays: one for all "used" previews (usedPreviewNodes) and one for all "not used"(notUsedPreviewNodes)
• As previews nodes are created, add them to the usedPreviewNodes
• As the user contracts the region, mark any extra nodes as "not used" and add them to notUsedPreviewNodes

Object Pool

• "Not used" nodes are tagged with a class that sets display: none
• If the user expands the region, convert the usedPreviewNodes, and then recycle any notUsedPreviewNodes
• When the user is done previewing the template, set these arrays back to empty arrays (to prevent memory leaks)

Object Pool

• Instead of removing the preview nodes (which triggers reflow), we hide them
• Why is this faster?
  • Less reflow == better performance

1. Expand to 53 tables

• 53 tables in usedPreviewNodes
• 0 tables in notUsedPreviewNodes

2. Contract to 22 tables

• 22 tables in usedPreviewNodes
• 31 tables in notUsedPreviewNodes
  • ​These nodes are hidden, but not removed!

3. Expand to 76 tables

• 22 nodes repositioned
• 31 notUsedPreviewNodes recycled
• 23 new nodes created

Performance Impovement?

Start to End

Original

Refactored

Performance Data

Original

Refactored

Pros

• Template previews are much faster!!
• Smoother user experience

Cons

• Have to wait to generate actual tables
  • "Working..." UI block
  • My opinion: This impact of this tradeoff is minimal
  • More important to ensure that performance is good for very interaction-heavy features

The End