1

Scalable Scalable Vector Graphics:

Automatic Translation of Interactive
SVGs to a Multithread VDOM for Fast Rendering
Michail Schwab , David Saffo , Nicholas Bond , Shash Sinha ,
Cody Dunne , Jeff Huang , James Tompkin , and Michelle A. Borkin

Abstract—
The dominant markup language for Web visualizations—Scalable Vector Graphics (SVG)—is comparatively easy to learn, and is open,
accessible, customizable via CSS, and searchable via the DOM, with easy interaction handling and debugging. Because these attributes
allow visualization creators to focus on design on implementation details, tools built on top of SVG, such as D3.js, are essential to the
visualization community. However, slow SVG rendering can limit designs by effectively capping the number of on-screen data points, and
this can force visualization creators to switch to Canvas or WebGL. These are less flexible (e.g., no search or styling via CSS), and harder
to learn. We introduce Scalable Scalable Vector Graphics (SSVG) to reduce these limitations and allow complex and smooth visualizations
to be created with SVG. SSVG automatically translates interactive SVG visualizations into a dynamic virtual DOM (VDOM) to bypass
the browser’s slow ‘to specification’ rendering by intercepting JavaScript function calls. De-coupling the SVG visualization specification
from SVG rendering, and obtaining a dynamic VDOM, creates flexibility and opportunity for visualization system research. SSVG uses
this flexibility to free up the main thread for more interactivity and renders the visualization with Canvas or WebGL on a web worker. Together,
these concepts create a drop-in JavaScript library which can improve rendering performance by 3–9× with only one line of code added.
To demonstrate applicability, we describe the use of SSVG on multiple example visualizations including published visualization research.
A free copy of this paper, collected data, and source code are available as open science at osf.io/ge8wp.

Index Terms—Visualization Systems, SVG, Performance, Virtual DOM, Rendering, D3.js.

1 I NTRODUCTION
CALABLE Vector Graphics (SVG) is the dominant markup to lower-level pixel-based interfaces such as Canvas and WebGL.
S language for visualizations on the web. The format is open
and comparatively easy to learn, and the SVG document object
For instance, in one 2009 Firefox benchmark [37], Canvas is
≈ 4× faster than SVG for rendering 600 circles. These gains are
model (DOM) is accessible, searchable, and easy to customize wrought by bypassing the DOM and requiring the user to provide
with CSS. As data is represented via individual elements, it is their own higher-level object (and data binding) abstraction, but this
easy to add interaction to these elements, and to select and debug approach is harder to learn, causes more difficult implementation
them when necessary. The data visualization community has built and debugging, loses the useful searchable and CSS customizable
infrastructure around SVG with tools like D3.js [7], which enable properties of SVG, and makes element-wise interactions more
fast development because data are bound to visual mark objects like difficult to implement. While object-level abstraction libraries have
<circle> and <rect> in the SVG DOM. The success of this open been proposed to simplify the development process for Canvas and
format is in part due to Web browser tools that help developers WebGL [31], none have yet gained a critical mass within the visual-
inspect and debug element appearance and behavior. With the help ization community. Similarly, browsers have recently added support
of these tools, it is easy to learn from and adapt existing SVG for the new OffscreenCanvas feature [40], which can parallelize
markup, leading to many visualizations being created using SVG. drawing work and increase performance. But so far, few visual-
In these respects, SVG is essential to the visualization community. izations take advantage of these options for higher performance
However, this flexibility comes at a price: as dataset size because they are challenging to use. Community investment in SVG
increases and the corresponding number of DOM nodes grows, continues as it is easier and more flexible for visualization proto-
SVG-based visualizations become slow. Even a minor DOM typing and development; yet the performance problems remain.
update triggers the browser rendering pipeline which includes The research question we address is how the SVG specification
full re-calculation of styles, layout, updating the DOM layer of visualizations — which is important to the community — may be
tree, painting, and compositing. This overhead can lead to slow de-coupled from the browser-based SVG rendering — which does
performance for animation and interaction even with only a few not sufficiently scale. To answer this question, we explored multiple
hundred nodes, which acts as a significant limitation on the space new visualization system ideas by analyzing the state of the art
of possible visualization designs and datasets. and the background relevant to data visualization. We discovered
For rendering and interaction performance, the community turns several shortcomings and identified research opportunities for
data visualization system research. First, we studied whether and
how JavaScript function calls meant to populate and update the
• Michail Schwab, David Saffo, Nicholas Bond, Cody Dunne, and Michelle DOM can be intercepted and redirected to instead reliably and
A. Borkin are with Northeastern University. E-mail: {schwab.m, saffo.d,
bond.n, c.dunne, m.borkin}@northeastern.edu. efficiently target a virtual DOM (VDOM). Specifically, we focused
• Shash Sinha, Jeff Huang and James Tompkin are with Brown University. on a common scenario in data visualization: updating attributes
E-mail: {ssinha11, jeff huang, james tompkin}@brown.edu. of many elements at once. Second, we explored communication
Manuscript received April XX, 20XX; revised August XX, 20XX. strategies to effectively maintain a VDOM on a worker thread
 2

Setup
Line Marks
12,000
Implementation
SVG & D3
SVG
Rendering
7 FPS
Interaction Delay
151 ms
Contribution: SSVG
Rendering
36 FPS
Interaction Delay
21 ms
Fig. 1. Viegas & Wattenberg’s popular wind map visualization is written for the Web using Canvas for its rendering speed (http://hint.fm/wind/).
Implementation via the more-familiar SVG and D3.js is comparatively simple and enables element-level events for interaction, styling with CSS, and
element inspection, but results in slow rendering at 7 frames per second (FPS). Using SSVG, via one line of additional code, we reach 36 FPS. This
is faster than the original Canvas implementation. Live at ssvg.io/examples/windmap.

including SharedArrayBuffers. Again, we optimized for common show SSVG’s applicability in visualization research in a real-world
data visualization usage patterns of SVGs. Third, we introduced research project that uses SSVG published at CHI 2020 by Klamka,
the usage of the new OffscreenCanvas element to offload the Horak and Dachselt, researchers unaffiliated with the authors [23].
rendering work from the main thread to the worker thread. This We release SSVG as open source software for interactive
effectively provides the first accessible multi-thread solution visualization developers to use at ssvg.io and osf.io/ge8wp. Beyond
for web-based information visualization. Fourth, we enabled the SSVG system, we contribute:
element-level interactivity common in SVGs even when rendering • The concept of automated translation from interactive DOM to
Canvas visualizations. We do this by performing hitbox testing dynamic VDOM, de-coupling SVG specification and rendering,
on the VDOM and re-triggering JavaScript events on the hidden • A communication technique to efficiently maintain a dynamic
DOM events so that JavaScript event listeners can capture them. VDOM on a worker thread,
We developed, implemented and bundled these concepts into • An optimized rendering approach that batches the drawing of

Scalable Scalable Vector Graphics (SSVG): a drop-in JavaScript many elements and that uses OffscreenCanvas without additional
library for D3.js which can ‘scale’ SVG performance to that of burdens for visualization creators,
a native Canvas reimplementation. Depending on code complexity, • Recommendations for visualization system creators based on

SSVG works with as little as one line of code. SSVG is the first our lessons learned, including research opportunities in the areas
system able to continuously render a dynamic SVG as Canvas of accessibility, expressivity and responsiveness which take
or WebGL, which dramatically improves rendering performance advantage of the availability of a dynamic VDOM.
and reduces DOM overhead. In addition, SSVG is the first
web-based visualization system to take advantage of parallel 2 A M OTIVATING E XAMPLE
rendering. This approach frees the main thread from rendering Jasmine is a student who has taken a data visualization course
and asks it only to process simulation computations, interaction and learned basic Web development and D3.js. She sees Viegas &
handling, and VDOM updates. For example, adding SSVG helps Wattenberg’s wind map [39] and feels inspired to better understand
the computationally-intensive calculation of a force-directed graph the chosen encodings by interactively editing them. She right-clicks
layout converge much faster while maintaining an interactive the map and looks for “Inspect” to change the map’s color via CSS,
visualization (see Figure 12 & Figure 11). but is surprised to find instead “Save image as...”: the visualization
We evaluated the robustness of SSVG by applying it to 25 is rendered via Canvas, which only allows exporting as an image
visualizations taken from bl.ocks.org. We find that SSVG works on and has no DOM to inspect. Jasmine investigates to find that the
24 of them without any code changes, and that changing 2 lines of Canvas visualization is over 1,000 lines of pure JavaScript.
code allows the one remaining visualization to work with SSVG. Undeterred, Jasmine re-makes the visualization as a learning
Further, we evaluated SSVG’s efficiency on four rendering-heavy exercise. Using D3.js, she binds the wind data to line elements
visualizations. SSVG improves rendering performance by 3−9×, in her SVG and, with 200 lines of JavaScript code, creates the
and shows a speedup in network layout visualization stabilization visualization seen in Figure 1. With moderate effort, she has imple-
from 16 seconds to 5 seconds. We show that SSVG increases its mented it in a format open to inspection, CSS manipulation, and
performance twice as much as SVG given an increase in CPU power. modification in editors such as Inkscape or Illustrator. However, she
We also demonstrate the increased ease of development for complex quickly realizes why Canvas was used, as Jasmine’s SVG windmap
data visualizations with a remake of a famous wind map visualiza- has three problems: First, the rendering happens at such a low frame
tion (Fig. 1) and a node-link visualization of the IEEE Information rate (7 FPS) that she sees individual images rather than continuous
Visualization conference co-author network (Fig. 11). Finally, we motion. Second, the browser becomes slow to respond to interaction
 3

Frames per second (FPS) 0 10 20 30 40 50 60 DOM

Javascript Update Style Layout Paint Composite
Perception Images Motion Smooth Very Smooth

Fig. 3. Chrome’s rendering pipeline performs these steps on the main

Fig. 2. Perception of frame rates between 0 and 60 FPS. At least 24 FPS
thread at its tick rate after any JavaScript code updates the DOM: Style,
are required to “tolerably” perceive motion [3] as opposed to individual
Layout, Paint and Composite. In some cases, these steps take just as
images, and 30 FPS and above are perceived as smooth.
much time as the visualization’s JavaScript code itself even though that
work is often unnecessary for visualization, such as re-applying CSS
input like click or scroll. Third, the wind particle paths contain rules when styles have not changed or positioning and layering HTML
visible corners, which is an artifact of not being able to compute elements even though SVG does not support these features. SVGs are
the wind paths smoothly without causing additional render time. much simpler to render than HTML, yet browser rendering does not take
advantage of their simplicity. Figure adopted from [17].
When Jasmine hears about SSVG, she visits ssvg.io and simply
copies a one-line script tag into her HTML file. With no other [19], [27], [32]. Bostock, Ogievetsky, and Heer write that “a suffi-
changes, the visualization rendering performance increases to 36 cient frame rate is necessary for fluent interaction and animation”,
FPS and browser interaction performance increases sevenfold. The and that “results also indicate that browser vendors still have some
browser’s main thread is also now free enough to quadruple particle distance to cover in improving SVG rendering performance” [7].
computations for smooth path traces. If she now wishes to change This is supported by literature on human psychology: for brushing
the appearance via CSS, she disables SSVG momentarily and and linking, for example, visual feedback is recommended to appear
tweaks the CSS in the browser developer tools. Once she decides within 50–100 ms to support human perception [4], [10], [26].
on a new style, she re-enables SSVG for higher performance. Compute time is the time required to complete calculations
necessary for a visualization. Force-based network visualizations,
for example, require many iterations to compute a stable layout
3 BACKGROUND
for user interpretation. A long compute time until the visualization
3.1 SVGs in Information Visualization Research is ‘ready’ can turn away users, as shown by Liu and Heer [26].
Online information visualization relies heavily on SVG. We com-
piled a list of the software technology used in Web visualizations 3.3 The Browser and SVG
from the 2018 proceedings of the IEEE Information Visualization
In this subsection, we analyze the browser setup commonly used
conference (InfoVis), available in the supplemental material, by
on web-based data visualizations. We identify usability issues that
reading paper descriptions, reviewing online demos, and contacting
we recommend visualization system researchers to tackle.
authors. We started with all 47 InfoVis papers, excluded work with-
out interactive web-based visualizations, and learned the technology
3.3.1 Processes and Threading
of 27 papers. Of 27 examples with known technology, 23 used SVG.
Of the remaining four publications, two used Canvas and two used Consider Google Chrome as an example of a modern browser.
WebGL. For example, Wang et al. [38] “used SVG for visualizing Chrome runs a top-level ‘browser process’ with its own dedicated
the animations, as it is easier to operate on the SVG elements and threads to handle user input and draw UI elements. Each Website
the efficiency of SVG is acceptable for our project”. On the other instance runs in its own ‘render process’, such as in individual tabs.
hand, Jo et al. [22] wrote their application with “the HTML5 Canvas Each render process has a main thread, responsible for everything
API to support visualizing tens of thousands of nodes and edges.” shown and interacted with on the page, from rendering the page con-
This trade-off is understood within the community: researchers gen- tents itself to computing which DOM object the pointer clicked on.
erally prefer to use SVG unless they are forced to switch technolo- Apart from low level operations on the graphics card, SVG
gies for performance reasons. We aim to enable researchers to inves- visualizations are rendered on the render process main thread. To
tigate complex data visualizations with their preferred technology. respond to input requests such as clicks, the main thread must
finish rendering a frame before it can react to user input. In other
words, visualization rendering performance is typically the same
3.2 Metrics as interaction performance; 4 FPS rendering would delay user
To help describe browser SVG performance and our alternative input by 250 milliseconds. Likewise, any computation required for
approach, we introduce three performance metrics: rendering a visualization’s simulation would happen every 250 milliseconds.
performance, interaction delay, and compute time. Challenge 1: Rendering, interaction, and simulation computa-
Rendering performance describes the speed at which a tion are performed on the main thread, which does not take advan-
visualization is re-rendered. This speed is measured in frames tage of multi-core CPUs. This slows rendering, hampers interactiv-
per second (FPS), where FPS of ≈30 are perceived as continuous ity, and increases compute times — even if other CPUs are idle. We
motion (Figure 2). FPS can affect task performance, e.g., below explore strategies to decouple these processes and parallelize work.
30 FPS, performance decreases in first-person games [11].
Google’s Web Fundamentals performance model states: “Users 3.3.2 Render Process Pipeline
are exceptionally good at tracking motion, and they dislike it when The render process pipeline governs a significant portion of the
animations aren’t smooth. They perceive animations as smooth rendering time of DOM-based visualizations like SVG—typically
so long as 60 new frames are rendered every second” [16]. The up to half. This is supported by Google’s Web Fundamentals
question we seek to answer is how rendering performance can be documentation: “Each of those frames has a budget of just over
increased as much as possible while retaining SVG’s flexibility. 16ms (1 second / 60 = 16.66ms). In reality, however, the browser has
Interaction delay is the response time of the browser and web- housekeeping work to do, so all of your work needs to be completed
site to user input, such as clicking. High interaction delay (feeling inside 10ms. When you fail to meet this budget the frame rate drops,
“laggy”) takes control away from the user and stops a visualization and the content judders on screen. This is often referred to as jank,
from feeling interactive. According to Google, websites should and it negatively impacts the user’s experience” [17].
respond to user input, such as a click, within 100ms [16], and After JavaScript is executed to perform changes to the DOM
numerous studies recommend 40–400ms depending on task [18], (including any SVG DOM changes), the browser must translate
 4

this markup into pixels visible on the screen. On Google Chrome, to use the OffscreenCanvas element would need to implement
the steps which are performed on the main thread are shown in their custom logic for rendering the specific visualization, for
Figure 31 : Style, Layout, Paint, and Composite. The Style step communicating updates from the main thread to the renderer thread,
applies rules specified in CSS, the Layout step lays out elements and to support interactivity. Interactivity is particularly challenging
on the website, the Paint step decides which areas get filled with because knowing what visualization elements were interacted with
what color, and the Compositing step resolves layering questions requires position information that typically lives on the rendering
and requests output. These modular steps happen one after another, thread. Further, if a lot of data must be updated, such as in a large
each taking the output of the previous step as input. node-link visualization, communicating the new node positions
While this ordering always ensures correct rendering, it also loses is costly, and the overhead needs to be managed. To our knowl-
context which could make the rendering faster. For example, when edge, OffscreenCanvas has never been used by the information
only the position of one circle element is changed by JavaScript, visualization research community to improve visualization render
the style rules are still re-parsed and re-applied to every SVG node performance. We find a way for visualization creators to easily take
in the DOM because the Style step requires the complete DOM advantage of the new OffscreenCanvas element by streamlining
as input. In fact, at the browser’s tick rate, the whole pipeline is communication between threads and by minimizing changes to
triggered any time anything on the DOM is accessed or edited. visualization development for increased adoption.
While browsers try to keep track of “dirty” elements and regions
to avoid unnecessary work, their to-spec implementation has to be
conservative and is more optimized for HTML than for SVG. Fur-
3.5 Related Work
ther, while in HTML, developers can specify nodes that should be
assigned individual compositing layers for joint transformations of 3.5.1 Canvas and WebGL Libraries
nested elements, such optimizations are not enabled for SVG. With
a sufficient number of DOM nodes, the time spent in unnecessarily Significant progress has been made in simplifying the use of Canvas
performed work in the render process pipeline is often greater than and WebGL for information visualization. Vega [34], shown in
the time spent in the visualization’s JavaScript code. Figure 4, uses a custom declaration to specify the visualization and
Challenge 2: The expensive render pipeline is triggered for create a scene graph, which can be rendered as SVG or WebGL.
any SVG DOM updates, which can slow down rendering with Three.js [9] is a general-purpose WebGL library which abstracts
re-applying previously completed work on unchanged nodes. We some low-level implementation details of WebGL programming.
use the knowledge of what DOM changes have occurred to avoid PixiJS [14] is a 2D WebGL rendering library which simplifies the
unnecessary work and explore additional strategies that minimize complexities of WebGL scenes, cameras, and GPU sprite loading.
work by communicating information across rendering steps. Proton [21] is a WebGL library which comes with many predefined
behaviors and physics simulations for particle rendering. For net-
work visualizations, vis.js [1] and Cytoscape [12], [36] provide fast-
3.4 The OffscreenCanvas HTML Element
rendering and configurable visualizations. These libraries signifi-
Newly added to the document of Web standards—the HTML Living cantly simplify parts of the challenges of developing visualizations
Specification—in Section 4.12.5.3 [40] is the OffscreenCanvas with WebGL. However, they have a higher barrier of entry than
element: “an HTMLCanvasElement but with no connection to the SVG for designing custom visualization since they require either
DOM. This makes it possible to use Canvas rendering contexts in Canvas/WebGL knowledge or knowledge of these less familiar
[web] workers.” To date, Chromium-based browsers support Off- libraries, and there is little compatibility with existing visualizations
screenCanvas, such as Google Chrome and Microsoft’s new Edge and workflows compared to the open standard of SVGs.
browser, as well as Opera [30]. Mozilla Firefox allows enabling Other libraries propose paradigms closer to the DOM. Stardust
OffscreenCanvas in the settings, with official support coming soon. [31] is a library which provides a data-binding abstraction for
OffscreenCanvas implies that rendering can happen on a separate WebGL visualizations and reduces the required effort to create 2D
thread without blocking the main thread and without triggering the data visualization in WebGL. Two.js [8] has a similar objective,
render process pipeline for DOM updates. The OffscreenCanvas and replicates some DOM advantages such as CSS-like styling.
is linked to a Canvas DOM element, and changes on the Offscreen- Paper.js [24] defines a programming interface to more easily define
Canvas appear instantly in the browser window – no manual transfer Canvas visualizations that are also statically exportable as SVG.
of the OffscreenCanvas image is needed. This is an opportunity for While promising, these tools are not yet widely used in the
the data visualization community with many potential applications. information visualization community. Two possible reasons are
Simulation-intensive visualizations would not slow down a separate that Canvas and WebGL are less flexible to style (no CSS) and
rendering thread, e.g., with expensive node position calculations. are harder to debug in the browser. Another reason is that each
Likewise, drawing-intensive visualizations can render in a separate framework proposes its own application programming interface
thread to free up the main thread for faster interaction performance (API), and a consensus on which to standardize has yet to form
and simulation. Finally, removing rendering from the main thread within the community. We believe that switching to one of these
could improve the overall interaction performance of the browser, APIs with their own language is counterproductive to the sharing
which currently must wait for a response from the render process and extending tools necessary for a vital visualization ecosystem.
before responding to general UI requests which relate to the page. In contrast, SVG is already an open standard with widespread
Challenge 3: To achieve parallelization through rendering support and widely-used infrastructure such as D3.js. None of
on an OffscreenCanvas, the main thread needs to efficiently these tools aim to improve existing visualizations and support
communicate to the render thread what to render—effectively the established and preferred infrastructure. While changes in
replacing the DOM analysis functions provided by the render visualization creators’ workflows are sometimes desirable, e.g., for
process pipeline. Conventionally, visualization creators wishing more expressivity, we see a switch from the open standard of SVGs
to a custom API due to performance reasons as detrimental to the
1. Mozilla is currently developing and rolling out GPU-based threaded paint-
ing and compositing for Firefox, called WebRender [2]. For simplicity of expo- ecosystem. We advocate for extending the rendering capabilities
sition and due to its popularity, we use Google Chrome as our example browser of SVGs to strengthen this open and expressive format.
 5

Familiarity in Visualization Intermediate Output

Community Creator Input Representation Generation
SVG Updated SVG
Specification DOM Renderer
HTML CSS JS (e.g. D3.js)

SSVG
Translate into Batch VDOM Updates, Updated Worker
VDOM Updates Send to Worker VDOM

Vega Parse Updated

Specification Declaration Scene Graph
Plain Text

Canvas Canvas
Specification Renderer
JS

WebGL WebGL Rendering

Specification Renderer Performance
JS

Fig. 4. A high level comparison of how visualization creators specify and define data visualizations in different languages and frameworks, and how these
specifications are then rendered by the browser. Green denotes specifications familiar to the data visualization community and fast renderers, red denotes
specifications less familiar to the community and slow renderers. Bridging the gap between the familiar SVG Specification and the fast Canvas and
WebGL Renderers is a crucial challenge for data visualization system research to allow the community to use their preferred language even on large data
sets. Translating the SVG Specification for automatic application to a Canvas or WebGL Renderer is a difficult process that SSVG tackles with a VDOM.

3.5.2 Canvas and WebGL with D3.js or not. Likewise, existing solutions do not maintain the valuable
D3.js [7] can render to Canvas by specifying a custom namespace, properties of SVG like CSS styling, and do not provide consistency
appending so-called custom elements, and then defining a custom with the SVG API. Existing VDOM implementations require
Canvas draw function for each element type such as circles and custom implementations and are not useful for multi-threaded
rectangles. This provides visualization creators some familiarity visualization, and no current visualization systems support
within the Canvas environment and helps manage data binding rendering on a web worker. This is a large set of challenges
to virtual elements. However, implementing the draw functions and opportunities for data visualization system research, as data
requires time and familiarity with Canvas, and the use of D3.js visualization can benefit from progress in all these areas.
in this way does not provide the advantages of styling via CSS. We build upon existing technology and infrastructure which is
Some projects convert SVG visualizations into Canvas already in use by the information visualization community, and
renderings, e.g., by extracting the rendered SVG as pixels and avoid custom APIs while still increasing SVG performance. To take
pasting the bitmap or rendering a textured quad into a Canvas. advantage of multi-threading, we create a VDOM implementation
This does not increase performance as more work must be optimized for communication of SVG properties across threads
completed. Other projects, such as canvg [25], render SVG simply based on JavaScript function calls to the DOM.
elements individually in a Canvas. Canvg supports many SVG In Figure 4, we display a high-level overview comparison of dif-
features, including definition-based complex gradients. However, ferent visualization creator inputs and the corresponding rendering
canvg is optimized for static SVGs and one-time rendering. outputs across different visualization systems. The SVG specifica-
tion as input allows visualization creators to design with HTML,
3.5.3 Virtual DOM CSS, and JavaScript, such as D3.js, but typically requires going
The concept of VDOMs is widely known and well adopted through the browsers’ slow DOM pipeline and SVG renderer. Other
to improve DOM update performance, particularly in frontend systems, such as Vega, Canvas and WebGL require less familiar and
JavaScript frameworks such as React [13], Vue.js [41], Angular less open languages to specify the visualization, but allow usage
[15], and many others. These frameworks use optimized VDOM of the faster rendering performance. We propose for visualization
implementations to efficiently update the DOM but, to our systems to bridge this gap between desired visualization creator
knowledge, no frameworks exist to intercept DOM changes to input and desired rendering engine. SSVG achieves this by parsing
populate a VDOM. Furthermore, efficiently maintaining a VDOM SVGs and JavaScript DOM calls, translating them into well-defined
on a worker thread requires effective communication that is hard VDOM updates, sending batched VDOM updates to a worker, and
to achieve because the worker thread has no access to the DOM. rendering the VDOM as Canvas or WebGL on the worker.
One work-in-progress project, WorkerDOM [5], implements
synchronization of the DOM across web workers to support a
small number of compute-heavy operations; however, it does not 4 G OALS
consider rendering nor our scenario of coping with updates on Drawing from our insights on the browser’s rendering pipeline and
many thousands of visualization elements per frame. lessons learned from related work, we arrive at the following goals
for Scalable Scalable Vector Graphics (SSVG):
3.5.4 Summary G1: SVG Format: As shown in Sec. 3.1, the information
To our knowledge, prior work has yet to enable rendering of visualization community relies on SVGs and is familiar with D3.js.
interactive or animated SVG visualizations as Canvas, smooth We believe that SVG is a natural fit for data binding because of the
 6

User’s Visualization Code SSVG: Scalable Scalable Vector Graphics

HTML CSS Main read Web Worker
Hide SVG, Create Canvas
Virtual DOM (VDOM)
Parse & Apply CSS
Init Read Code
Render
Copy to VDOM

JavaScript Offscreen
Canvas

node =

node

node Create VDOM Nodes

Update Capture
Update Aributes Re-render

Mapping between VDOM and DOM

Re-trigger Event on Find DOM

DOM node Node

Find VDOM
Interaction Capture Node from Event
Canvas Event Position

Fig. 5. Overview of SSVG’s architecture and how it enables a conventional nodelink diagram written with D3.js to be rendered smoothly. From left
to right, the diagram shows the user’s visualization code, SSVG’s main thread tasks, it’s internal representation of the DOM, and the Canvas rendering
in a web worker. Methods that read and write on the DOM are overridden to instead operate on the VDOM, which is used to render the Canvas. The
browser rendering pipeline is largely skipped because DOM updates are avoided.

availability of elements (to which data can be mapped). We also the reader understand the system’s inner workings, but this is not
believe that since SVG allows inspection and is customized more required for understanding later sections of the paper.
easily in browsers’ developer tools as well as with CSS, reviewing
existing SVG code is more conducive to learning than Canvas
5.1 Overview and Alternative Strategies
implementations. We want SSVG to be SVG-based.
G2: Interactivity: Interactivity plays a big role in data At a high level, SSVG circumvents browsers’ render process, as
visualizations. Enabling listeners on elements rather than absolute we have identified this pipeline to be too slow for high interactivity
positions eases interactivity implementation, as Canvas-based and rendering performance (G2 & G3). Any system designed to
visualizations have to manually infer which data point was hovered circumvent the DOM for custom rendering needs a VDOM as
or clicked. In SSVG, we wish to enable element-based listeners an internal representation of the visualization so that it can be
as they exist on SVG. rendered. Flexibility exists in the approach of obtaining a VDOM,
G3: Rendering Performance: To address SVG’s main in the format of the VDOM, and in the rendering technique.
shortcoming, we wish to make the technology scalable to more SSVG obtains a VDOM by intercepting JavaScript calls which
elements so that more data can be displayed. For a smooth user would normally affect the SVG DOM. SSVG’s approach causes
experience, the rendering performance should be at least 20–30 no interaction with the Webpage’s own DOM, and avoids the costs
FPS, see Sec. 3.2. associated with browsers’ render pipeline. SSVG uses the DOM
G4: Load on main thread: To aid scalability, slow rendering function calls to maintain a VDOM and records associated styles
should impact the user experience as little as possible. We wish to from relevant CSS. This approach has the benefit of not introducing
perform rendering on a separate thread such that the main thread a new API and not requiring workflow changes for visualization
can prepare the next frame concurrently. Little free time on the creators, but comes with some challenges to interpret the JavaScript
main thread can also lead to slow visualization layouts, such as calls correctly. The much more common approach of obtaining a
network visualizations. We aim to keep the load on the main thread VDOM is via custom APIs, or via templates such as in React [13]
low to maximize browser interaction performance, and for quick or Angular [15]. This approach is possible for visualization systems,
layout computations. but reduces compatibility with existing systems such as D3.js.
SSVG draws the VDOM on an OffscreenCanvas in its own
render thread, but also allows single-thread use. This requires us to
5 S YSTEM automatically communicate all required VDOM information across
In this section we describe Scalable Scalable Vector Graphic the separate main and rendering threads. We implement efficient
(SSVG)’s core concepts, its architecture, implementation, browser communication via SharedArrayBuffers: a low-level technology for
support, features, limitations, future work, and how these address sharing integers across JavaScript workers. Our implementation
our design goals. We also include technical information to help focuses on canvas rendering and optimizes the canvas drawing calls.
 7

An alternative strategy is to use WebGL for rendering. WebGL events on the original SVG elements after they occur on the Canvas
rendering is fast when the information needed to render is largely element. To find the correct SVG element on which to trigger an
contained within the graphics card, and little communication is event, the matching VDOM element must be identified based on
needed to update the image. This is unfortunately not the case for the event position. SSVG achieves this with manual hitbox testing,
general-purpose rendering systems, as they have no information but for speed it performs this only on elements which received a
about what is causing the data updates. Therefore, for cases like listener function from the visualization. To allow event listeners to
this, the WebGL performance is expected to be similar to Canvas. receive events without delay, hitbox testing needs to occur on the
Our choice to use OffscreenCanvas is in line with our goal to main thread. To support hitbox testing on the main thread, the main
improve interactivity and to reduce the load on the main thread thread needs to have a partial copy of the VDOM that contains
(G2 & G4), but other systems could reduce our communication position information of elements. For a smooth user experience
overhead and complexity with single-thread rendering at the cost (G2), it is important to minimize discrepancies between the main
of some interactivity and rendering performance. thread VDOM, which users interact with, and the render VDOM,
Put together, SSVG is a system for turning main-thread-rendered which is used to display the visualization. SSVG minimizes the
SVG visualizations into multi-threaded visualizations. It achieves discrepancy by only applying changes to the main thread VDOM
higher rendering performance, low interaction delays, and low when the render thread is done rendering and ready to update its
computation times with minimal code changes — many existing VDOM for rendering a new frame. SSVG’s fast parallel rendering
visualizations are accelerated simply by importing ssvg.js with also contributes to an immediate response to user interaction.
one line of code. For other cases, we describe limitations and
workarounds in Sec. 5.5.
5.3 Cross-thread Communication
To allow the worker thread to render the visualization, the main
5.2 Description thread has to communicate all VDOM data and keep the worker
To support interactive visualizations built with SVG (see G1 and VDOM up to date by sending updates when they occur. To prevent
G2 in Sec. 4), we want to enable fast rendering on visualizations race conditions, the main thread saves the local VDOM updates
implemented with D3.js with as few changes as possible. To until the rendering thread informs the main thread that it is done
achieve fast rendering (G3), we address challenges 1 and 2 rendering the last frame and is ready to receive updates for a new
identified in Sec. 3.3 by taking the rendering work off the main frame. We identify three main requirements for the communication:
thread and using a tight connection between the rendering steps Lightweight Communication: Serializing large messages
in Figure 3 to avoid unnecessary work. for JavaScript’s postMessage is expensive. To minimize delay,
We address these issues with the design of SSVG by maintaining message sizes need to be small even when communicating updated
an up-to-date virtual DOM (VDOM), only re-applying CSS for data for thousands of node attributes.
new or changed elements, and using the VDOM to render the Reliable Identification: Because messages are serialized, no
visualization in a separate worker. In Figure 5, we explain these VDOM node references can be transferred, and changed nodes
concepts through an example of a node-link visualization: have to be identified based on a specified message protocol.
Init (top arrow, blue): To set up the VDOM and the Canvas However identifiers, such as element selectors, can be unreliable;
element, SSVG parses the SVG and extracts any potential the communication happens asynchronously and the changes may
contained elements and copies them to the VDOM. Stylesheet effect the DOM and VDOM structure. For example, the commands
rules are parsed. The original SVG element is hidden and replaced “move the fifth SVG element to the right, then delete the fourth
with a new Canvas element of the same size at the same position. SVG element, then move the fifth SVG element down“ need to be
Control over the Canvas contents is then passed to the Web Worker, executed in the correct order so that the element that is moved to the
which is responsible for rendering. right and the element that is moved down are not the same element.
Update (middle arrow, orange): When a visualization attempts Efficient Computation: It is important to consider the
to access the DOM, the operation is re-routed to the VDOM. computational cost of generating the update messages on the main
This is achieved by capturing JavaScript function calls such as thread as well as decoding and applying the update on the worker
appendChild(), setAttribute(), and getAttribute(). In thread. Importantly, the main thread has to generate a message that
this way, visualizations do not modify the DOM when calling uniquely assigns the new values to specific elements. If element
setAttribute(). Meanwhile, the visualization remains naive to selectors are used to identify nodes, efficient ways to generate
these processes and continues to operate as usual. This is possible these selectors and intelligent ways of caching and updating these
because getAttribute() also accesses the VDOM instead of the selectors are needed. On the worker, the updates have to be applied
DOM. As a performance improvement, we intercept D3.js’ attr quickly without the need to look up nodes on an individual basis,
function which operates on a selection of nodes instead of indi- and fast iterations over the elements are desired.
vidual nodes. This helps minimize the overhead of mapping DOM To address these three requirements, visualization systems
to VDOM. But because this is only a performance improvement, aiming to support multi-thread VDOM updates for many nodes
SSVG works with other frameworks such as Vega and React. Calls need to explore different batching strategies for update messages.
to appendChild() determine the position of an element in the Before switching to our latest strategy, SSVG used hierarchy-based
VDOM, but are also used to fake hierarchy in the original elements lists of updates similar to how D3.js applies attribute changes to
so that visualizations can continue to rely on the DOM structure, a selection of elements with a common parent. Within the parent,
such as with element.parentNode. When accessing the DOM elements can be identified simply by their child index, and the
outside the SVG, SSVG passes on the information to the native worker can iterate over all children instead of looking them up
functions so as to not disrupt any non-SVG JavaScript on a website. individually. We paired this strategy with a selector-based method
Interaction (bottom arrow, purple): In SVG visualizations, event of identifying the parent element. Positive aspects of this approach
listeners are attached to DOM elements. With SSVG, no elements are that it is similar to D3.js, lists are only as big as the number
are appended to the DOM so event handling must work differently. of elements within a parent, and the worker can iterate over the
To support element-based interactions, SSVG manually re-triggers nodes efficiently if they have the same parent. On the other hand,
 8

Main read Render read 5.4 Implementation

SSVG is implemented in TypeScript, which is compiled and
DomHandler Main CanvasWorker bundled to JavaScript. One JavaScript file defines the main thread
behavior, and one file is created for the web worker. To avoid
loading multiple files, the main library file includes the worker
Available to both threads file as a Blob [28]. The internal architecture of SSVG is shown
in Figure 6. SSVG is modular, and different types of renderers can
VDOM CanvasRenderer DrawingUtils be used. We provide our own optimized Canvas renderer as well as
a basic implementation of a WebGL renderer using Stardust [31].
Fig. 6. SSVG’s internal architecture. The main file sets up the Canvas and When overlaps are not an issue, the order of drawing calls is not
passes it to the CanvasRenderer through the CanvasWorker if Offscreen- important. For such cases, SSVG’s default rendering behavior is to
Canvas is supported, or directly otherwise. The main file intercepts function group elements within the same parent by color, begin a rendering
calls such as setAttribute() to DOM objects and captures the initiated
attribute changes in the DomHandler. These changes are propagated
path, follow the path of all these elements, and then apply a single
to the local VDOM as well as to the renderer VDOM. The renderer uses stroke and fill for them all. This approach dramatically speeds
the up-to-date VDOM and included utility functions to draw the Canvas. up rendering. As a fallback for visualizations in which the order
within a parent is important, this option can be turned off and the
Canvas renderer draws each element individually.
the selector-based approach is difficult to implement reliably
When OffscreenCanvas is available for rendering, SSVG creates
because of the asynchronous communication and simultaneous
a worker which uses the renderer on a separate thread. For browsers
structural changes. The biggest issue with this earlier approach
which do not yet support OffscreenCanvas, the Canvas renderer is
is that it relies on a flat hierarchy for its performance: if
used directly. As a consequence, SSVG does not require Offscreen-
many nested elements are changed simultaneously, e.g., with
Canvas to work. We show a performance comparison between
d3.selectAll(’g’).select(’circle’).attr(), they have
single-thread usage of SSVG and SSVG with two threads in Sec. 7.
to be identified individually. This can result in slow performance.
The DomHandler manages the mapping between DOM elements
We decided in our final implementation on a strategy that and the corresponding VDOM elements so that interactions can
identifies all elements by a global element index within the be propagated to the correct elements. The DomHandler lives on
visualization, assigned upon creation of the element. This strategy the main thread since the Web Worker has no access to the DOM.
avoids referring to elements by their selectors, which makes The CanvasRenderer only uses the VDOM to render since it has no
this approach more reliable. New attribute values are simply access to any elements if it is being called from the renderer thread.
communicated via an array, and the index within the array refers to
the global element ID. This approach minimizes context that needs
to be communicated within the update messages, but can lead to 5.5 Features and Limitations
larger arrays. The biggest benefit of this array-based approach is SSVG supports JavaScript features frequently used in SVG
that the computation on both threads is straightforward, and the information visualization such as adding and removing elements,
worker can simply iterate over the array and assign the values to setting and reading attributes, setting CSS classes, and setting
the elements with the corresponding global element IDs. Therefore, styles via CSS and via the style attribute. At michaschwab.github.
for each type of attribute changed, one single array is needed to io/ssvg-tests/, we track SSVG’s rendering quality by comparing
communicate the new values. it with SVG’s rendering output across a growing set of examples.
To additionally improve communication performance, This allows us to work on supporting more advanced SVG and
we use SharedArrayBuffers [29]. These are part of the CSS features while maintaining the established capabilities. The
ECMAScript 2017 standard and were added to browsers recently. full list of supported and experimental features is available on the
SharedArrayBuffers are low-level arrays which can only contain testing website. SSVG does not yet support SVG definitions such
integer values, to prevent any harmful content from being as arrow heads, advanced path settings such as stroke-dasharray, or
transmitted. We currently use SharedArrayBuffers to communicate SVG animations. D3.js functions with complex DOM operations,
cx, cy, x1, x2, y1, y2, x, and y attributes. These are such as nested data selections or reordering SVG elements in
frequently-updated position attributes, e.g., to move circles, the DOM, have limited support within SSVG. We aim to add
rectangles, and lines. Since more than integer-level precision is implementations for these features in the future to support more
required to avoid flickering of node positions, the message also use cases. Generally, visualizations can achieve the same DOM
contains information about the encoding of the values in the changes through simpler operations that are already supported by
SharedArrayBuffers. We typically multiply position values by a SSVG, such as D3.js transitions instead of SVG animations, and
factor of 100 before converting to integers. This information is then single-depth data selections with nested elements instead of nested
used by the worker to decode the values and to receive float values. data selections. SSVG has a growing implementation of CSS and
Combining these approaches, our update messages follow the supports rule priorities. We will support more features in the future
format shown below. The portion of the data that is not sent via based on prioritized importance for the visualization community.
SharedArrayBuffers is sent as part of the “raw” data and supports
arbitrary values such as strings. For the rest, pointers to the
SharedArrayBuffers are transferred, along with the information 6 U SING SSVG
of what types of attributes their values refer to, such as “cx”. SSVG currently works on visualizations with D3.js version 3, 4,
and 5. In most settings, users simply have to include a new script
const updateData = { tag on their website. The automatic version of SSVG detects SVG
raw: {fill: [’red’,’red’,’blue’], visualizations on the website and automatically enables SSVG
class: [’group1’, ’group1’, ’group2’]}, with default settings:
shared: {cx: bufferX, cy: bufferY}};
<script src="//unpkg.com/ssvg/ssvg-auto.js"></script>
 9

SVG Setup SSVG

Rendering Rect Marks Rendering
14 FPS 5,000 58 FPS
Interaction Delay Implementation Interaction Delay
71 ms SVG & D3 17 ms

5
Turns
18
Turns

Fig. 7. A sample visualization which counts the completed turns for particles moving in a circle, rendered with SVG (left) and SSVG (right) over one
minute each. While the particles have made 18 turns with SSVG, only 5 turns were completed with SVG. The number of particles is gradually increased.
SSVG’s rendering contains more particles for a given framerate, demonstrating its higher performance. Live on ssvg.io/examples/donut.

If more control is desired, visualization creators can use the

manual version with new SSVG(). This can be used to create
separate instances of SSVG for multiple SVGs, in which case
separate web workers would be created for each visualization. The
manual version also allows passing settings:
<script src="//unpkg.com/ssvg/ssvg.js"></script>
<script>new SSVG({
safeMode: false, useWorker: true,
getFps: function(fps) { console.log(fps); }
});</script>
The settings (see ssvg.io/docs) include:
safeMode (default false): With safeMode enabled, SSVG renders
all elements individually. This is closest to SVG-based rendering.
useWorker (default true): If supported, use a Web Worker.
getFps: A function which receives the current rendering
performance. The FPS drops to 0 for visualizations with no
animation to avoid unnecessary work.
Fig. 8. A set of 12 SSVG data visualizations. The visualizations were taken
We recommend minimizing the use of transformations for x and as-is from bl.ocks.org and were not modified for SSVG usage beyond
y positions, as these are difficult to optimize. In general, little work including a script tag. Live at ssvg.io/examples.
is needed to enable SSVG on a D3.js visualization.
varies, in one benchmark we find SSVG performs similarly to the
6.1 Debugging with SSVG speed of a native Canvas implementation. Further, we show that
While a VDOM is maintained in memory, one drawback of SSVG’s SSVG can be used for current research in two examples. First,
Canvas rendering is that the VDOM elements are not readily we re-create an example publication from IEEE VIS 2018 [35]
available for browser inspection. This can make development with SSVG which was originally implemented with canvas, demon-
more difficult, and does not allow easy access to the elements for strating that work which typically happens offline or in complex
users of the visualization. To support continued SVG debugging Canvas or WebGL environments can be implemented and shared
even on SSVG-rendered visualizations, we provide a toggle to in the D3.js and SVG format which is better understood by the
switch back to SVG rendering for development purposes. Once community. Second, we show how SSVG was used in a CHI 2020
SSVG is included, re-loading a website with an svg parameter visualization publication to render visualizations on wrist bands of
will temporarily disable SSVG. For example, if vis.com loads smart watches [23]. Finally, on a IEEE VIS authorship network visu-
a SSVG visualization, then vis.com?svg disables SSVG and alization, we demonstrate that expanding the scope of SVG enables
allows traditional browser-based inspection. If unfamiliar users visualization creators to focus on visual marks during development.
attempt to inspect a SSVG visualization, a comment in the HTML
explains that this is an SSVG visualization and provides the URL 7.1 Bl.ocks.org
to enable SVG inspection. Thus, the workflow is to debug in SVG
but toggle SSVG to monitor performance. Final presentation is in To test the general applicability of SSVG to D3-based data
SSVG; should another user ‘Inspect’ the visualization, they will see visualizations on the Web, we selected a set of 25 examples from
instructions to toggle SSVG and view the SVG DOM as normal. bl.ocks.org to try SSVG on without any code changes. We selected
the visualizations based on interactivity, animations, and amount
of data to test SSVG’s stability across challenging conditions.
7 U TILITY With the only change to the visualizations being to load SSVG,
We demonstrate the utility of SSVG for visualization in practice SSVG fully worked on 24 out of the 25 visualizations. Twelve of
and in research, and evaluate it on common visualizations and visu- the correctly-working visualizations are shown in Figure 8. The one
alization sizes. SSVG works out of the box on 24 of 25 D3.js (v3, visualization that did not work correctly actually renders correctly,
v4, v5) visualizations found on bl.ocks.org. In four benchmarks, we but only very slowly. An analysis revealed that the visualization
show that SSVG renders 3–9× faster than SVG. While performance unnecessarily deleted and re-created many of its elements in each
 10

Rendering Performance Comparison Between Techniques Performance Comparison with Shapes between SVG and SSVG
Very Smooth 60 60

Very Smooth
SSVG with Stardust
SSVG with Canvas
50 Native 50
Average Frames Per Second

Average Frames Per Second

Stardust SSVG
Circle
40 Code Native 40 Rectangle
Canvas
Smooth

Smooth
rewrite Line
needed A Text
30 30

SSVG with Canvas

SSVG with Stardust
Motion

Motion
20 20
Single thread
SVG
SVG Circle
10 10 Rectangle
Line
Images

Images
A Text
1,000 5,000 10,000 15,000 20,000 25,000 30,000 1,000 5,000 10,000 15,000 20,000 25,000 30,000
Number of Rectangles Number of Nodes
Fig. 9. Rendering performance comparison between SVG (blue), SSVG Fig. 10. Rendering performance comparison between SVG and SSVG for
(yellow), SSVG with Stardust using WebGL (orange), custom native text, circle, rectangle, and line primitives. SSVG outperforms SVG across
implementations of the same visualization for Canvas (green) and Stardust all tested shapes. Around 17,000 lines, SSVG’s performance is lower than
(cyan), and a single-threaded version of SSVG and SSVG with Stardust with more and fewer nodes. This anomaly requires further investigation.
(yellow and orange, dash-dotted) that shows how much multi-threading
contributes to SSVG’s performance. At 20,000 nodes, the SVG only ren- Results: The performance results for rectangles are shown in
ders at about 6 FPS, leading to jank and a bad user experience. Meanwhile,
both SSVG implementations render at about 55 FPS, on par with and even Figure 9. At 15,000 nodes, SSVG renders about 9× faster than
outperforming custom native implementations of the same visualization SVG, and overall about on par with a custom native implementation
in Canvas and WebGL. Data and implementations at osf.io/ge8wp. of the visualization for Canvas. To stay above a rendering
performance of 30 FPS, SVGs limit data visualization creators to
frame. Because updates occur much more frequently in data visual- about 2,500 data points, whereas SSVG supports about 35,000 data
izations than node creations, SSVG is more optimized for updating points at the same frame rate without any code changes; a 14-fold
attributes, and creating an element involves the additional cost increase. Even for browsers that do not yet support the multi-thread
of transferring the information across threads. A two-line change setup, SSVG still allows up to 14,000 data points. This shows
in the visualization code prevented the unnecessary deletion and that the bigger contributor to SSVG’s performance improvement
re-creation of elements, and cause SSVG’s rendering to be smooth. over SVG is the ability to render dynamic SVGs as Canvas, side-
With this change, all 25 interactive visualizations work with SSVG. stepping the browser’s rendering pipeline by intercepting JavaScript
While we are working on continuously growing our support function calls without any changes to the SVG visualization code.
for SVG features, we demonstrated here that SSVG works a CPU Scaling: To compare performance across different CPU
large subset of D3.js visualizations to be of immediate use to the powers, we measure SVG and SSVG performance on a computer us-
visualization community. At ssvg.io/examples, we present a list of ing full CPU clock speed, as well as using only half the CPU’s clock
SSVG-rendered visualizations. At osf.io/ge8wp, we document the speed. Given twice the CPU performance, SVG’s performance
evaluation of the 25 example visualizations with testable demos. increased by 50%. However, SSVG increased its performance by
100%. As there is less overhead, SSVG can better take advantage
7.2 Benchmark of the faster CPU. On a fast computer, SSVG performs even faster
than the native Canvas implementation because multi-threading is
To measure our success in achieving goal G3: high performance more advantageous there. This data is included at osf.io/ge8wp.
rendering, we take a D3.js SVG data visualization and compare Smart Phones: Initial benchmarks on smart phones show
its performance against SSVG rendering. We create a simple average of a 55–60% rendering performance increase for 1,000–
visualization with many marks but little computationally-heavy 10,000 rectangles on an iPhone SE iOS 11 for Chrome 73 and
work (Figure 7). Data points move in a circle at varying radii and Safari 11, and an average of 180% speedup for a Pixel 3 device.
speeds (also visible on ssvg.io). WebGL: When evaluating our basic Stardust WebGL renderer
Visualization: For the benchmark, we use a simplified version of (see Sec. 5.4), we found similar performance compared to the
the circular visualization: All elements are gray and begin moving Canvas-based worker. Based on these results, our impression is
immediately. We gradually increase the number of data points with that the Canvas renderer is already quite optimized for this use
a step size of 100 nodes and average the rendering performance over case and little improvement can be made by switching to WebGL.
a time period of 6 seconds at each step. We create a native Canvas Conclusion: These benchmarks show how that a speedup of
implementation for the same visualization to compare performance. up to 9× is possible, and our results in Figure 10 show that this
Setup: For software, we use Google Chrome version 78. For speedup is consistent across different shapes. In the next sections,
hardware, we use a Apple MacBook Pro (16-inch, 2019) with we demonstrate real-world applicability: We analyze the utility of
32 GB memory, an 2.4 GHz 8-Core Intel Core i9 processor and SSVG for a previously-published VIS paper technique, describe
AMD Radeon Pro 5500M 8 GB graphics card, capped at a 60 FPS how SSVG was used in a research project published at CHI by re-
tick rate by the OS and hardware display. Performance will vary searchers unaffiliated with the authors, and discuss more examples.
across devices due to varying hardware and software. Additional
results for other hardware, including smart phones, is provided at
osf.io/ge8wp and briefly described below. Also note that the frame 7.3 Probabilistic Graph
rate results also imply corresponding interaction delay: for single- Faster Web rendering with SSVG would allow our community to
thread systems, such as SVG and Canvas, the interaction delay is share more complex designs or data with online demos. We could
equivalent to the FPS because interactions can only be picked up then collectively learn from these online demos because they are
when the rendering process is done. For SSVG’s multi-threading, created and shared in a familiar format. To demonstrate this aspect
interaction performance is at least as high as rendering performance. of SSVG’s utility to the data visualization research community,
 11

SVG
Circle Marks Setup
Rendering
1,000
16 FPS SC Line Marks Implementation
Interaction Delay
CP TM 2,500 SVG & D3
61 ms JH NE
JF
PD
JD JW
DW
Layout HP AB
MS AS OD
16 seconds JH BL AL
HS
PI
MS

WC
MM NR
KM
SSVG JS
HQ
Rendering
44 FPS
Interaction Delay
23 ms
TD
Layout
5 seconds KM

Authorship Map

Fig. 11. IEEE VIS Information Visualization paper authors of the last 10 years, visualized by a combination of geolocation and co-authorship of
papers [33]. Author nodes are sized by number of papers and colored by affiliation. Authors with at least 8 papers are shown with initials, such as
Hanspeter Pfister (HP) or Sheelagh Carpendale (SC). Visualization researchers on the US East coast often collaborate with Europe, and researchers
from Australia tend to collaborate with the US and Europe. Several authors are placed far from their institution. For example, Tim Dwyer (TD) and Huamin
Qu (HQ) are placed far from Australia and Hong Kong, respectively, due to co-authorships with collaborators in the US and Europe. Without SSVG,
this visualization’s layout takes 16 seconds to compute, whereas with SSVG, the layout only takes 5 seconds and the visualization renders smoothly.

SSVG
SVG
Rendering
Setup
Rendering
et al. [20], we explore the co-authorships of researchers depending
Implementation
9 FPS SVG & D3 23 FPS on location. We use multiple forces to determine authors’ positions
Interaction Delay Rectangle & Line Marks Interaction Delay on the visualization, for which D3.js provides excellent support:
117 ms 6,000 44 ms
Layout
A collision force prevents node overlaps and a geoposition
Layout
79 seconds 27 seconds force determines an author’s position on the map. Co-authors
are linked and pulled toward each other, whereas researchers
without collaboration are repelled. A combination of these forces
moves authors close to their affiliations, but allows collaborations
to have a significant impact on their position (Figure 11). The
visualization is available online at ssvg.io/examples/infovis and
has been presented as a IEEE VIS 2019 poster [33].
We created this visualization by starting with an example
Fig. 12. A graph layout with 6,000 elements rendered with SSVG. This network graph on bl.ocks.org [6], added a map background, and
could be used as a starting point to make Schulz’ work [35] open and
accessible on the Web. SVG renders at 9 FPS, and layout takes 79
defined custom forces to move nodes to the desired locations. We
seconds to stabilize. SSVG renders at 23 FPS and arrives at a stable did not have to learn the API of a network visualization library
layout in 27 seconds. Available at ssvg.io/examples/probabilistic. nor implement custom drawing functions. Instead, we were able
to benefit from forces and colors provided by D3.js, and SSVG
we present an example case where SSVG could be used to make is able to render the visualization smoothly (44 FPS instead of 15
available online recent research which was completed offline. FPS) and quickly produces a stable layout (5 seconds instead of
In 2017, Schulz et al. [35] developed probabilistic graph 16 seconds). In this familiar workflow, we can add other forces
layouts including uncertainty, drawing thousands of nodes and provided by D3.js to experiment with different layouts, or style
marking clusters. Unfortunately, the work was completed offline, nodes differently with CSS. We believe maintaining the D3.js
making the results difficult to share. Here, we create a SVG-based design process is helpful to data visualization research.
visualization with similar visual encoding to demonstrate feasibility
of rendering similarly structured networks with many nodes. Our 7.5 Windmap
implementation is a two-layer force layout where the node groups
We developed a remake of Fernanda Viegas and Martin Watten-
repel each other, and individual nodes are pulled toward the node
berg’s popular wind map [39], as illustrated in Sec. 2 and Figure 1,
group centers. Our recreated visualization contains 6,000 elements
to demonstrate that particle visualizations are feasible with SVG
(Figure 12). SSVG increases rendering performance from 9 FPS to
when SSVG is used for rendering. Our new implementation and
23 FPS and decreases the time to stabilize the network layout from
performance results are shown in Figure 1. Wind is visualized as
79 to 27 seconds. Our demonstration shows that rendering this
3,000 traces at a given time using four line segments with decreas-
probabilistic graph using a simple D3.js and SSVG implementation
ing opacity, or 12,000 individual SVG elements total. Opacities and
is feasible even with large datasets. While other factors, such as
colors are simply set with CSS, and the lines are drawn with D3.js.
availability of clustering algorithms, may have played a role in their
The SVG visualization renders too slowly and causes low browser
decision to implement their research offline, we want rendering
interactivity with this much data (≈ 7 FPS). Including the SSVG
performance to not dictate whether work can be shared online.
library immediately results in an improved performance of 36 FPS.
This new windmap visualization can now be customized easily,
7.4 Network Visualization such as styling path colors with CSS, and data binding makes
In this example, we demonstrate SSVG’s utility with the ability to the code’s structure clear. In Figure 13 we compare the SVG and
focus on design even in complex network visualizations. This is a SSVG rendering pipeline, demonstrating that SSVG performs faster
domain which typically requires heavy attention on implementation both by executing the rendering pipeline more quickly, as well as
due to the many visualized data points. Using data from Isenberg preparing the next frame while rendering via the multi-thread setup.
 12

SVG standard. Other possible extensions include the simplification

of existing features, such as the direct use of gradients or arrow
heads within SVG elements, as opposed to requiring separate SVG
definition elements to be created. We also hope that other work
will take advantage of a dynamic VDOM to target more devices,
such as done in the published e-Ink data visualization project, or to
automatically reposition or rescale elements to fit different screen
sizes such as smart phones. Lastly, the VDOM may also be useful
for systems that can make systematic accessibility adjustments
for visualizations, such as to improve contrast or systematically
avoid colors that are hard to distinguish by red-green colorblind
users. Because of the ability to automatically obtain a dynamic
VDOM for most DOM-based visualizations, such systems would be
applicable to a wide set of visualizations, often without necessary
changes, and a consistent set of accessibility settings could be
applied across these visualizations. To summarize, the ability to
Fig. 13. Chrome’s performance analysis on the windmap visualization
for SVG (top) and SSVG (bottom). In 300ms, SVG renders one obtain a dynamic VDOM allows visualization system researchers
frame, whereas SSVG renders five frames. Parallelization is a strong to customize visualization rendering to improve aspects such as
performance advantage, as well as saving costly DOM access and performance, expressivity, responsiveness, and accessibility.
avoiding the expensive browser rendering pipeline. 2. VDOM to Worker: Our work showcases that a VDOM can
be automatically synchronized to a worker thread to parallelize
7.6 e-Ink Data Visualization work. Our approach bundles VDOM updates and sends the
SSVG is open source and has already been used in research data to the worker thread via JavaScript worker messages and
projects published at CHI. Klamka et. al used SSVG to efficiently SharedArrayBuffers. Clearly defined update messages, such
render data visualizations on e-Ink devices [23], which can render as ones with unique element identifiers, have the advantage of
images but not SVG. The researchers implemented their data synchronizing the VDOM on the worker more robustly, but come
visualizations using SVG and D3.js, their preferred technologies, with significant overhead in message size and work to update the
and use SSVG to render images on the devices. We canvassed their VDOM element-by-element, rather than allowing grouped attribute
opinion via personal correspondence: “I don’t know any libraries changes. To support fast rendering of thousands of elements,
for Canvas that are as powerful as D3.js, and using D3.js allows us we minimize lookups of individual elements and batch attribute
to re-use previously created visualizations. With SSVG, we don’t changes. This comes with challenges of uniquely identifying
need to implement hit testing or give up inspecting DOM elements. elements if elements are removed and added at the same time as
SSVG can be a useful tool because researchers often have to decide they are being modified, and we do not yet support nested D3.js
between smooth rendering and the flexible experimentation with selections that further complicate the update structure. These
the relatively easy D3.js implementation that they are used to.” trade-offs between synchronization approaches should be explored
They noted that SSVG is easy to use: “The first steps are super in future visualization systems aiming to enable parallel work.
easy, and there are good examples on the website [..]. You need 3. Canvas Renderer: Our renderer connects the paths of all
a little bit of time to get used to debugging, switching back to the elements within the same parent element that have the same color.
SVG, but even that is pretty straightforward. If things don’t work, This speeds up rendering, but the grouping changes the order in
you can check if the normal SVG worked to check if the issue is which elements are painted. In some cases, this can change the
in your code or in how SSVG translated it to Canvas. [..] Even our layering of elements compared with the original SVG. SSVG
new students are getting the hang of it and are able to use SSVG comes with a fallback option to render elements individually to
well. It’s working out nicely.” However, some shortcomings exist: more reliably arrive at the same result as SVG rendering. Ideally, an
“Not yet all features of D3.js are supported. [..] I try to avoid D3.js’ intelligent renderer would identify which elements can be grouped
nested selection groups, as SSVG seems to struggle with that”. into batched paint calls without layering issues, and which elements
need to be rendered individually. To further speed up rendering and
to increase reliability, data visualization system researchers should
8 D ISCUSSION explore strategies to intelligently group Canvas drawing calls.
SSVG consists of multiple techniques that are executed in a pipeline 4. OffscreenCanvas Rendering: SSVG demonstrates that
to take data visualizations created with SVG, CSS, JavaScript, and multi-thread rendering using OffscreenCanvas is possible for data
D3.js, and render them smoothly in a separate thread. Below, we visualizations without additional technical burdens on visualization
discuss each step before discussing high level points. creators. To achieve this, SSVG synchronizes the SVG VDOM to
1. DOM to VDOM: This research demonstrates that it is the worker thread. Other possible architectures could make multi-
possible to populate a VDOM based on the DOM, and keep it up threading easier for canvas visualizations, e.g., by sending Canvas
to date by intercepting and redirecting JavaScript DOM function drawing calls to the worker, as opposed to sending a virtual DOM.
calls. The ability to automatically obtain an interactive VDOM, and Future visualization system research should explore these and
de-coupling the SVG specification from SVG rendering, opens up other strategies to make OffscreenCanvas useful and feasible for
many opportunities for data visualization system researchers that data visualization creators. Beyond OffscreenCanvas specifically,
want to minimize changes to the visualization creation workflow our work shows that giving visualization researchers the ability
based on SVG and D3.js while being able to customize visualization to customize rendering allows us to benefit from new technologies.
output. In this work, the VDOM is used for fast rendering of This may be advantageous for data visualization when further
thousands of nodes. Other works may focus on extending the capa- future technologies are released. For example, Vulcan is a new
bilities of SVGs, such as introducing z-index attributes to manage graphics and compute API that is currently starting to be supported
the layering of elements, which is not possible with the current by browsers, and the ability to customize rendering allows the data
 13

visualization community to take advantages of new developments changes in their way to create visualizations, and hope that this
such as these while also benefiting from the open format of SVGs. approach will inspire more work that adds to existing infrastructure.
Overall, SSVG combines several existing and new ideas to Ultimately, we hope to contribute to the success of the visualization
achieve Canvas- and WebGL-based rendering on a worker thread ecosystem by making Scalable Vector Graphics more scalable.
of traditional SVG and D3.js visualizations. Each step — DOM,
CSS and JS → VDOM → worker VDOM → Canvas/WebGL ACKNOWLEDGMENTS
drawing — comes with opportunities and trade-offs. SSVG focuses We thank Alex Ahmed, Sara Di Bartolomeo, Aditeya Pandey, Lulu
on replicating SVG and DOM capabilities most efficiently with Liu, and Laura South for experimenting with SSVG and providing
optimized communication and rendering, and other systems may useful feedback and advice. This work was supported by the
focus on other aspects, such as added expressivity and accessibility. Khoury College of Computer Sciences, Northeastern University.
Custom APIs: The benefits of by-passing the browser’s
rendering pipeline can also be achieved by using Canvas directly, R EFERENCES
or by using one of the available frameworks that provide a custom
[1] Almende B.V. vis.js: A dynamic, browser based visualization library.
API to design visualizations. While this solution makes sense in http://visjs.org. Accessed: 2019-03-29.
special cases, we believe it is important for the data visualization [2] D. Anderson. Mozilla GFX Team Blog: Off-Main-Thread Painting.
ecosystem to continue to invest in the open, inspectable, and https://mozillagfx.wordpress.com/2017/12/05/off-main-thread-painting/.
flexible format of SVG, and build on established works like D3.js. Accessed: 2019-03-31.
[3] P. Bakaus. The Illusion of Motion. https://paulbakaus.com/tutorials/
Advantages over Browser-Based Rendering: The perfor- performance/the-illusion-of-motion/. Accessed: 2019-03-29.
mance gains of SSVG are achieved by replacing the normal browser [4] D. H. Ballard, M. M. Hayhoe, P. K. Pook, and R. P. N. Rao. Deictic
rendering process, by batching attribute changes, by avoiding work codes for the embodiment of cognition. Behavioral and Brain Sciences,
20:723–767, 1995. doi: 10.1017/s0140525x97001611
on unchanged nodes, and by taking advantage of new multi-thread [5] K. Baxter. WorkerDOM: JavaScript Concurrency and the DOM.
technology. In each step, we take advantage of how data visual- https://github.com/ampproject/worker-dom. Accessed: 2019-12-04.
izations are typically created: CSS rules typically do not change [6] M. Bostock. Force-directed graph. https://observablehq.com/@d3/
over time, many SVG features are rarely needed, and many nodes’ force-directed-graph. Accessed: 2019-03-29.
[7] M. Bostock, V. Ogievetsky, and J. Heer. D3 data-driven documents. IEEE
attributes are often changed at once. This domain knowledge of how Transactions on Visualization and Computer Graphics, 17(12):2301–2309,
SVGs are typically used in the data visualization domain allows Dec. 2011. doi: 10.1109/TVCG.2011.185
us to make assumptions, simplifications, and performance improve- [8] J. Brandel. Two.js: A renderer agnostic two-dimensional drawing api
for the web. https://two.js.org. Accessed: 2019-03-29.
ments that are not possible for browser vendors without breaking [9] R. Cabello. Three.js: 3D Javascript Library. https://threejs.org. Accessed:
backward compatibility. Through public discussions and personal 2019-03-29.
communication with the Google Chrome SVG team, we have [10] S. K. Card, A. Newell, and T. P. Moran. The Psychology of Human-
advocated for systematic improvements to SVG rendering. In some Computer Interaction. L. Erlbaum Associates Inc., Hillsdale, NJ, USA,
1983.
cases, we were successful: as part of the discussion surrounding [11] M. Claypool, K. Claypool, and F. Damaa. The effects of frame rate and
our suggestion to add a “bulk setAttribute” function on many nodes resolution on users playing first person shooter games. Proceedings of
at crbug.com/978513, improvements in the existing setAttribute SPIE - The International Society for Optical Engineering, 6071, 01 2006.
doi: 10.1117/12.648609
function were identified, implemented and deployed in Chrome that [12] Cytoscape Consortium. Cytoscape: Network data integration, analysis,
speed up its execution by about 20%. We continue to work with the and visualization in a box. https://cytoscape.org. Accessed: 2019-03-29.
Chrome team to share our lessons learned. However, from our dis- [13] Facebook. React. https://reactjs.org/. Accessed: 2019-12-04.
cussions, it is clear that substantial improvements, such as the 3–9× [14] Goodboy Digital Ltd. Pixijs: The HTML5 creation engine.
http://www.pixijs.com. Accessed: 2019-03-29.
speedup provided by SSVG, are not feasible for browser vendors [15] Google. Angular. https://angular.io/. Accessed: 2019-12-04.
because they can not make the assumptions and simplifications that [16] Google. Web fundamentals: Measure performance with the RAIL model.
we can make within the data visualization community. Therefore, https://web.dev/rail/. Accessed: 2019-03-29.
we argue that community-driven visualization systems are a useful [17] Google. Web fundamentals: Rendering performance. https:
//developers.google.com/web/fundamentals/performance/rendering/.
path toward greater SVG performance in data visualization. Accessed: 2019-03-29.
[18] W. D. Gray and D. A. Boehm-Davis. Milliseconds matter: an introduction
9 C ONCLUSION to microstrategies and to their use in describing and predicting interactive
behavior. Journal of experimental psychology. Applied, 6 4:322–35, 2000.
We contribute Scalable Scalable Vector Graphics (SSVG): a doi: 10.1037/1076-898X.6.4.322
JavaScript library for faster rendering and interaction of Scalable [19] H. Gueziri, M. J. McGuffin, and C. Laporte. Latency management
in scribble-based interactive segmentation of medical images. IEEE
Vector Graphics (SVG). As this is a foundational technology Transactions on Biomedical Engineering, 65(5):1140–1150, May 2018.
for the visualization community, we hope SSVG will enable the doi: 10.1109/TBME.2017.2777742
development of new and complex data visualizations on the Web. [20] P. Isenberg, F. Heimerl, S. Koch, T. Isenberg, P. Xu, C. Stolper,
We show that SSVG automatically enables a 3–9× performance M. Sedlmair, J. Chen, T. Möller, and J. Stasko. vispubdata.org: A
metadata collection about IEEE visualization (VIS) publications. IEEE
boost on four rendering-intensive visualizations. We use an online Transactions on Visualization and Computer Graphics, 23(9):2199–2206,
collection of data visualizations to demonstrate compatibility. Sept. 2017. doi: 10.1109/TVCG.2016.2615308
We believe that enabling visualization creators to use their [21] A. Jie. Proton: JavaScript particle engine. https://a-jie.github.io/Proton/.
generally-preferred technology—SVG—allows them to increase Accessed: 2019-03-29.
[22] J. Jo, F. Vernier, P. Dragicevic, and J. Fekete. A declarative rendering
the number of iterations within the design process because it is a model for multiclass density maps. IEEE Transactions on Visualization
high-level specification with CSS customizability. This may aid and Computer Graphics, 25(1):470–480, Jan 2019. doi: 10.1109/TVCG
researchers to focus on the visual design and interpretation, rather .2018.2865141
[23] K. Klamka, T. Horak, and R. Dachselt. Watch+strap: Extending
than on Canvas and WebGL implementation details. With SSVG, smartwatches with interactive strapdisplays. In Proceedings of the ACM
we encourage continued SVG-based visualization research because CHI Conference on Human Factors in Computing Systems, CHI’20.
the result is open, meaning it can be easily customized, analyzed ACM, 2020. doi: 10.1145/3313831.3376199
and learned from—crucial elements for research. To visualization [24] J. Lehni and J. Puckey. Paper.js — The Swiss Army Knife of Vector
Graphics Scripting. http://paperjs.org. Accessed: 2019-12-04.
system designers, we show how Canvas rendering and multi- [25] G. Lerner. canvg: JavaScript SVG parser and renderer on Canvas.
threading can be integrated into users’ visualization without many https://github.com/canvg/canvg. Accessed: 2019-03-29.
 14

[26] Z. Liu and J. Heer. The effects of interactive latency on exploratory visual Nicholas Bond Nicholas Bond is a software
analysis. IEEE Transactions on Visualization and Computer Graphics, engineer at Voltus where he creates tools for
20(12):2122–2131, Dec 2014. doi: 10.1109/TVCG.2014.2346452 visualizing data related to power grids and energy
[27] R. B. Miller. Response time in man-computer conversational transactions. markets. Nicholas has a Bachelor of Science from
In Proceedings of the December 9-11, 1968, Fall Joint Computer Northeastern University in Computer Science
Conference, Part I, AFIPS ’68 (Fall, part I), pp. 267–277. ACM, New and Interaction Design.
York, NY, USA, 1968. doi: 10.1145/1476589.1476628
[28] Mozilla. MDN Web Docs: Blob. https://developer.mozilla.org/en-US/
docs/Web/API/Blob. Accessed: 2019-03-29.
[29] Mozilla. MDN Web Docs: SharedArrayBuffer. https:
//developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global
Objects/SharedArrayBuffer. Accessed: 2019-03-29.
[30] Mozilla Developer Network. The OffscreenCanvas Element.
https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas/ Shash Sinha Shash Sinha received the
OffscreenCanvas#Browser compatibility. Accessed: 2020-09-24. BE (Hons) Degree in software engineering
[31] D. Ren, B. Lee, and T. Höllerer. Stardust: Accessible and transparent from the University of Waikato, New Zealand,
gpu support for information visualization rendering. Computer Graphics in 2017, and the Sc.M. degree in Computer
Forum, 36(3):179–188, June 2017. doi: 10.1111/cgf.13178 Science from Brown University, USA, in 2020.
[32] W. Ritter, G. Kempter, and T. Werner. User-acceptance of latency in touch Currently employed at Amazon in Seattle, WA, he
interactions. In M. Antona and C. Stephanidis, eds., Universal Access incorporates modern visualization techniques in
in Human-Computer Interaction. Access to Interaction, pp. 139–147. his work regularly.
Springer International Publishing, Cham, 2015.
[33] D. Saffo, M. Schwab, M. A. Borkin, and C. Dunne. GeoSocialVis:
Visualizing Geosocial Academic Co-Authorship Networks by Balancing
Topology- and Geography- Based Layouts. IEEE VIS Poster, 2019. doi:
10.31219/osf.io/ykwah Cody Dunne is an Assistant Professor at
[34] A. Satyanarayan, K. Wongsuphasawat, and J. Heer. Declarative interaction Northeastern University. His research focuses on
design for data visualization. In Proceedings of the 27th Annual ACM applying data visualization and human-computer-
Symposium on User Interface Software and Technology, UIST ’14, pp. 669– interaction principles to real-world problems and
678. ACM, New York, NY, USA, 2014. doi: 10.1145/2642918.2647360 generalizing the results — often via design studies.
[35] C. Schulz, A. Nocaj, J. Goertler, O. Deussen, U. Brandes, and D. Weiskopf. He generally works with problems that combine
Probabilistic graph layout for uncertain network visualization. IEEE showing network topology, position in space,
Transactions on Visualization and Computer Graphics, 23(1), 2017. doi: values of attributes, changes to these over time,
10.1109/TVCG.2016.2598919 and how changes or events happen in sequence.
[36] P. Shannon, A. Markiel, O. Ozier, N. S. Baliga, J. T. Wang, D. Ramage, He received his Computer Science Ph.D. in 2013
N. Amin, B. Schwikowski, and T. Ideker. Cytoscape: a software and M.S. in 2009 from the University of Maryland.
environment for integrated models of biomolecular interaction networks.
Genome research, 13(11):2498–2504, 2003. doi: 10.1101/gr.1239303
[37] B. Smus. Performance of canvas versus SVG. https:
//smus.com/canvas-vs-svg-performance/. Accessed: 2019-03-29. Jeff Huang Jeff Huang is an Associate Professor
[38] Y. Wang, D. Archambault, C. E. Scheidegger, and H. Qu. A vector in Computer Science at Brown University. His
field design approach to animated transitions. IEEE Transactions on research in human-computer interaction focuses
Visualization and Computer Graphics, 24(9):2487–2500, Sep. 2018. doi: on behavior-powered systems, spanning the
10.1109/TVCG.2017.2750689 domains of mobile devices, personal informatics,
[39] M. Wattenberg and F. Viégas. Wind map. http://hint.fm/wind/, 2012. and web search. Jeff’s Ph.D. is in Information
Accessed: 2019-03-29. Science from the University of Washington in
[40] World Wide Web Consortium. HTML living standard: The Seattle, and his masters and undergraduate
OffscreenCanvas interface. https://html.spec.whatwg.org/multipage/ degrees are in Computer Science from the
canvas.html#the-offscreencanvas-interface. Accessed: 2019-03-29. University of Illinois at Urbana-Champaign.
[41] E. You. Vue.js. https://vuejs.org. Accessed: 2019-12-04.

James Tompkin James Tompkin is an assistant

professor of Computer Science at Brown
University. His research at the intersection
Michail Schwab Michail Schwab is an engineer of computer vision, computer graphics, and
and researcher at Google. His research is on the human-computer interaction helps develop new
scalability of the data visualization ecosystem, visual computing tools and experiences. His
working to allow visualizations to display more doctoral work at University College London on
data on more devices and be useful to more large-scale video processing and exploration
people. He works in the areas of interaction, techniques led to creative exhibition work in the
rendering, collaboration, and responsiveness Museum of the Moving Image in New York City.
for mobile visualizations and other form factors. Postdoctoral work at Max-Planck-Institute for
Micha received his PhD in Computer Science from Informatics and Harvard University helped create new methods to edit
Northeastern University, and his undergraduate content within images and videos. Recent research has developed new
degree in Physics from the University of Konstanz. machine learning techniques for view synthesis for VR, image editing and
generation, and style and content separation.

Michelle A. Borkin received a Ph.D. in 2014 and

an M.S. in 2011, both in Applied Physics, from
David Saffo David Saffo is a Ph.D. candidate at Harvard University in Cambridge, MA, USA. She
Northeastern University Khoury College of Com- is an Assistant Professor in the Khoury College
puter Sciences. Researching in the Visualization of Computer Sciences at Northeastern University,
@ Khoury lab, his work centers around immersive Boston, MA, USA. Her research interests include
analytics, virtual reality, and collaboration. This data visualization, human-computer interaction,
work is motivated by his passion for applying and application work across domains including
human-computer interaction research to new and astronomy, physics, and medical imaging.
emerging interdisciplinary areas.