JointJS performance with 15000+ components

[Shyamalan Chemmery]

Hi,

Is there a best practice for rendering and manipulating 15000+ SVG elements on a single drawing?

Right now, with @12000 elements, we are struggling with performance. Memory usage is touching @1G on just loading the diagram. Any operation on elements (like moving it around or adding elements) is quite laggy. Panning is virtually impossible. But, paging up/down/left/right using the paper scroller tab works fine.

Any help will be much appreciated.

Thanks & Regards

Shyam

[dave]

The most important part is the definition of shapes. We ourselves built applications that rendered >10.000 elements and links (counting to more than 80.000 SVG DOM elements) very fast and with instant interaction. There are couple things that are not exactly optimal when rendering bigger graphs. First, the JointJS special attributes such as ref-x, ref-y, ... (http://jointjs.com/api#SpecialAttributes). These are great for simple diagrams because they allow you to position SVG elements relatively to other SVG elements. However, this is not good for bigger graphs as JointJS has to first calculate the bounding box of the referenced elements in order to position the others. JointJS is pretty generic in lot of things which comes with a performance tradeoff. But if you stick to good techniques, you can achieve pretty good performance. Please see the example attached showing some of the techniques that we use. Here's an explanation:

1. joint.dia.FastPaper: this paper first renders into the document fragment asynchronously and dumps this fragment into the live DOM with each batch of cells added. Moreover, it disables the sortViews() method which normally sorts SVG elements in the live DOM according to the z-index set (the z property).

2. A good practice when creating new shapes is to always define a view and a model. The model only works with data while the view reacts on changes in this data and re-renders accordingly (see the initialize() method of the joint.shapes.basic.ConveyorElementView). Also, notice we completely skipped the 'markup' property containing SVG string in order to skip the repeated SVG parsing. We define the SVG DOM elements (innerRect/outerRect) and clone them in the overwritten renderMarkup() method. The rest of the code of the view just updates the SVG nodes when the associated model properties change. For this, we take advantage of the built-in Vectorizer SVG library (http://jointjs.com/api#v) which is our lightweight mini-SVG library.

Good news is that if you use these techniques, everything else in JointJS/Rappid will work as well. In other words, these tweaks don't break any core or plugins functionality.

It is possible to optimize even further using some smart techniques. For example, on the first render, the user probably does not see the whole diagram anyway so one can render only some part of the diagram and render the rest later on once the user scrolls or after a certain delay so that the paper contains only those elements/links that are visible in the viewport.

[Shyamalan Chemmery]

Hi Dave,

Many thanks for the prompt response...

I tried using the FastPaper code ... It works fine as long as you do not have links in the cells collection.

When we add links with the cells, we get the error 'Cannot read property el of undefined' in rappid.js line 6579 (we are using Rappid v1.6.1). Looks like, when the link is rendered the code falls over if the source or target cell has not been rendered.

We used joint.dia.Paper with async: true and it has improved loading time by 50%. Loading a drawing with @12000 components and links used to take @12 min. It has come down @6min. Panning is still not possible. We are trying out your suggestion of dynamically loading items. Will feedback on that...

Thanks & Regards

Shyam