Graph visualization efficiency of popular web-based libraries PDF Free Download

Name: Graph visualization efficiency of popular web-based libraries PDF
Author: Jodi Hernandez

1 / 17

2 views•17 pages

Graph visualization efficiency of popular web-based libraries PDF Free Download

Graph visualization efficiency of popular web-based libraries PDF free Download. Think more deeply and widely.

Zhaoetal.

Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

https://doi.org/10.1186/s42492-025-00193-y

ORIGINAL ARTICLE Open Access

permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the

original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or

other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line

to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory

regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this

licence, visit http://creativecommons.org/licenses/by/4.0/.

Visual Computing for Industry,

Biomedicine, and Art

Graph visualization eciency ofpopular

web-based libraries

Xin Zhao1, Xuan Wang1, Xianzhe Zou1, Huiming Liang1, Genghuai Bai1, Ning Zhang2, Xin Huang2,

Fangfang Zhou1 and Ying Zhao1*

Abstract

Web-based libraries, such as D3.js, ECharts.js, and G6.js, are widely used to generate node-link graph visualiza-

tions. These libraries allow users to call application programming interfaces (APIs) without identifying the details

of the encapsulated techniques such as graph layout algorithms and graph rendering methods. Eﬃciency require-

ments, such as visualizing a graph with 3k nodes and 4k edges within 1 min at a frame rate of 30 fps, are crucial

for selecting a proper library because libraries generally present diﬀerent characteristics owing to the diversity

of encapsulated techniques. However, existing studies have mainly focused on verifying the advantages of a new

layout algorithm or rendering method from a theoretical viewpoint independent of speciﬁc web-based libraries.

Their conclusions are diﬃcult for end users to understand and utilize. Therefore, a trial-and-error selection process

is required. This study addresses this gap by conducting an empirical experiment to evaluate the performance

of web-based libraries. The experiment involves popular libraries and hundreds of graph datasets covering node

scales from 100 to 200k and edge-to-node ratios from 1 to 10 (including complete graphs). The experimental results

are the time costs and frame rates recorded using the libraries to visualize the datasets. The authors analyze the per-

formance characteristics of each library in depth based on the results and organize the results and ﬁndings into appli-

cation-oriented guidelines. Additionally, they present three usage cases to illustrate how the guidelines can be

applied in practice. These guidelines oﬀer user-friendly and reliable recommendations, aiding users in quickly select-

ing the desired web-based libraries based on their speciﬁc eﬃciency requirements for node-link graph visualizations.

Keywords Graph visualization, Node-link diagram, Web-based visualization, Visualization library

Introduction

Node-link graph visualization is widely used to provide

a profound understanding of the global and local struc-

tures of a graph [1–7]. Implementing a node-link graph

visualization involves several advanced techniques,

including graph layout and graph rendering [8, 9]. Web-

based graph visualization libraries [10–12] such as D3.js,

ECharts.js, and G6.js have encapsulated graph layout

algorithms and graph rendering methods, allowing users

to easily generate node-link visualizations by selecting

application programming interfaces (APIs) without iden-

tifying the details of the advanced techniques. erefore,

using these libraries is the preferred option for end users

who regularly engage in graph visualization tasks, provid-

ing a convenient and eﬃcient way to generate node-link

visualizations.

Web-based graph visualization libraries present diverse

characteristics [13]. rough preliminary surveys with

end users, including front-end engineers, data analysts,

students, and academics, we investigated the factors they

consider when selecting a visualization library. Based on

their feedback, we identiﬁed three main factors that were

most frequently mentioned and prioritized by the end

*Correspondence:

Ying Zhao

zhaoying@csu.edu.cn

1 School of Computer Science and Engineering, Central South University,

Changsha 410083, Hunan, China

2 QAX Security Center, Qi An Xin Technology Group Inc., Beijing 100044,

China

Page 2 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

users: functional requirements, programming complex-

ity, and eﬃciency requirements. Functional requirements

can be easily conﬁrmed by viewing library documenta-

tion and online examples. Low-level encapsulated librar-

ies, such as D3.js, tend to have higher programming

complexity, whereas high-level libraries, such as ECharts.

js and G6.js, have lower programming complexity. How-

ever, the conﬁrmation of eﬃciency requirements requires

considerable trial and error owing to three complex,

interrelated factors: (1) time cost and frame rate, (2)

graph layout algorithm and graph rendering method, and

(3) numbers of nodes and edges.

Speciﬁcally, time cost refers to the duration required

for a library to generate a node-link graph visualization

result [8, 11]. Frame rate is the number of visualiza-

tion images displayed per second in a browser [14]. e

time cost and frame rate are mainly determined by the

graph layout algorithm and rendering method [8, 14].

Most graph layout algorithms require hundreds of itera-

tive calculations to determine node positions [15–19].

A rendering process follows each iteration. Each cycle

of the layout iteration and rendering process produces

one visualization image. erefore, graph layout itera-

tions and rendering processes contribute to the time cost

and frame rate. A low time cost enables users to quickly

obtain a stable graph visualization. A high frame rate

ensures a smooth graph-visualization animation during

the iteration calculations [20].

Typically, only information on the number of nodes and

edges is available to users, without a deep understanding

of graph layout algorithms and rendering methods, when

selecting a library to meet their eﬃciency requirements.

However, visualizing the same graph data using diﬀerent

libraries generally results in varied time costs and frame

rates [14, 21] because these libraries adopt diﬀerent lay-

out algorithms and support various rendering methods.

Moreover, the relationship between graph size and time

cost/frame rate is intricate. erefore, users must con-

duct experiments to verify the library that satisﬁes their

eﬃciency requirements. However, the trial-and-error

process is time-consuming and tedious.

To the best of the authors knowledge, systematic and

application-oriented guidance for end users in choosing a

web-based graph visualization library from the perspec-

tive of eﬃciency requirements is lacking owing to three

main reasons. First, library designers tend to provide the

functional features and usage examples of a library; how-

ever, they overlook specifying its eﬃciency advantages in

detail [22]. Second, software engineers may share their

experience of using one or two libraries on a few spe-

ciﬁc graphs; however, they have insuﬃcient time to sys-

tematically evaluate library eﬃciency. Finally, although

researchers have investigated the performance of existing

graph layout algorithms and rendering methods [23,

24], they have focused on demonstrating the advantages

of the newly proposed layout algorithm or rendering

method. eir eﬀorts are from a source-code level and

a theoretical viewpoint, independent of speciﬁc popular

web-based libraries, making it diﬃcult for end users to

understand and utilize their ﬁndings.

To address this gap, this study evaluated the per-

formance of web-based graph visualization libraries

through a systematic, controlled experimet. e experi-

ment involved three popular libraries: D3.js, ECharts.js,

and G6.js, and three rendering methods: scalable vec-

tor graphics (SVG), Canvas, and web graphics library

(WebGL), resulting in seven experimental library

entries: D3-SVG, D3-Canvas, D3-WebGL, ECharts-

SVG, ECharts-Canvas, G6-SVG, and G6-Canvas. e

study selected 481 graph datasets with node scales rang-

ing from 100 to 200k and edge-to-node ratios ranging

from 1 to 10 (including complete graphs(CGs)). Among

them, 156 datasets were sourced from real-world sce-

narios and 325 datasets were synthetic to overcover the

node scales and edge-to-node ratios. e experiment was

conducted on a mainstream desktop computer equipped

with a common browser and operating system. e time

cost and frame rate for generating node-link diagrams

using the libraries and datasets were recorded during the

experiment.

e time cost and frame rate results were thoroughly

analyzed. Performance trends and diﬀerences in the

experimental libraries with increasing node scales and

edge-to-node ratios were identiﬁed. e factors con-

tributing to these ﬁndings were summarized. e

experimental results and ﬁndings were reorganized into

application-oriented guidelines, and three usage cases

are provided to illustrate how the guidelines can be

applied for practical use. A end user with speciﬁc eﬃ-

ciency requirements (e.g., graph scales, time cost limits,

and acceptable frame rates) for generating node-link dia-

grams can identify suitable libraries by consulting our

guidelines. For example, if a user needs to visualize a

graph with 3k nodes at an edge-to-node ratio of 1 within

1 min while maintaining a frame rate above 30 frames per

second(fps), they can see that D3-WebGL and D3-Can-

vas meet these requirements.

In summary, this study presents a systematic evaluation

of the performance of popular web-based graph visuali-

zation libraries, an in-depth analysis of the performance

trends and diﬀerences in libraries, and application-ori-

ented guidelines to help end users identify suitable librar-

ies that meet their speciﬁc eﬃciency requirements for

quickly generating node-link graph visualizations.

Page 3 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

Graph visualization libraries

Graph visualization libraries can be categorized as either

desk-or web-based. Desk-based libraries are integrated

into desktop applications for local data visualization.

Popular examples of desk-based libraries include Tab-

leau, Matplotlib, JavaFX, and GTK+ [22]. ese librar-

ies are commonly used for visualization scenarios that

require local deployment and oﬄine data presentation.

Conversely, web-based libraries allow users to generate

graph visualizations in JavaScript-supported web brows-

ers. Popular web-based libraries include D3.js, G6.js,

ECharts.js, Sigma.js, Chart.js, NetV.js and, Linkurious.

js [10–12, 14, 25–27]. Web-based libraries oﬀer greater

accessibility, cross-platform compatibility, and easier

deployment than desktop-based libraries, making them

the preferred choice for most users. is study focuses on

web-based libraries.

Graph layout algorithms

Graph layout algorithms include force-directed [15–19],

constraint-based [28–30], and dimensionality reduction

[31–34] algorithms. Force-directed algorithms simu-

late node interaction forces using physical models such

as springs and particles to generate node-link visualiza-

tions. Representative algorithms include Spring [15],

Fruchterman-Reingold [16], Spring Embedder [17], and

ForceAtlas2 [18]. Although force-directed algorithms

produce visually appealing and easily understandable lay-

out results with low implementation diﬃculty, they have

high computational complexity and diﬃculty in achiev-

ing globally optimal layouts. Most graph visualization

libraries, including those selected in this study utilize

these algorithms [10–12, 14, 25–27]. Constraint-based

layout algorithms position nodes and edges based on

speciﬁed constraints such as node distances and posi-

tional limitations. Representative constraint-based lay-

out algorithms include grid, circular, and hierarchical

layouts [28–30]. ese algorithms oﬀer good ﬂexibil-

ity because they can achieve customized layout results

through user-deﬁned constraints. However, the design of

suitable and conﬂict-free constraints can be challenging.

Dimensionality reduction algorithms project nodes into

a two-dimensional space based on their characteristics in

a high-dimensional space. Classic dimensionality reduc-

tion algorithms include high-dimensional embedding

[31], pivot multidimensional scaling [32], and DRGraph

[33]. ese algorithms are known for their high layout

speeds. However, the projection process may lead to an

improper representation of local graph structures and a

low-readability layout result.

Graph rendering methods

Web-based graph visualization libraries rely on native

browser graphics methods (i.e., rendering methods) to

convert data into visible graphical representations. SVG,

Canvas, and WebGL are the three main methods used

to natively render graphics [24, 35, 36]. Each rendering

method has its own advantages. e SVG method uses

geometric shapes, paths, and texts to render graphs,

which can be scaled and resized without losing quality

and is ideal for creating interactive visualizations that

require precise control over individual elements. Can-

vas directly manipulates pixel-based data on a browser

surface, making it suitable for rendering animations and

other scenes with low interaction requirements. WebGL

is based on the Open Graphics Library [37] and ena-

bles users to create graphics processing units (GPUs)

to accelerate visualizations directly in the browser. It is

commonly used to create immersive three-dimensional

games, virtual reality experiences, and scientiﬁc simula-

tions [38–43]. Most web-based visualization libraries are

built using at least one of the three rendering methods.

For example, G6.js and ECharts.js stably support the SVG

and Canvas methods, whereas D3.js stably supports all

three rendering methods.

Methods

is study systematically evaluates the eﬃciency of pop-

ular web-based graph visualization libraries in terms of

time cost and frame rate. e ﬁndings could guide end

users in quickly selecting a library that meets their graph

visualization eﬃciency requirements based on the size

of the graph dataset. erefore, the authors conducted

a controlled experiment using popular web-based graph

visualization libraries and a considerable number of

various graph datasets. e details of the experimental

design are presented below.

Graph visualization library selection

D3.js, G6.js, and ECharts.js libraries were used in the

experiment based on three considerations. First, the

three libraries are popular open-sourced web-based

libraries that support node-link visualizations. ey

obtained GitHub stars of 108k, 58.7k, and 10.7k, respec-

tively, as of April 2024. Second, each supported at least

two rendering methods, facilitating an eﬃciency compar-

ison between the rendering methods. Finally, they were

created for diverse target audiences to ensure that the

experimental results can beneﬁt a wide range of users.

D3.js is tailored for professional developers with high

customization requirements because it provides numer-

ous APIs for manipulating the underlying data items and

graphical elements. However, D3.js has a relatively high

Page 4 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

development diﬃculty and a steep learning curve. G6.js

integrates many advanced graph visualization functions

and algorithms, making it suitable for senior data analysts

with specialized graph analysis requirements. Its devel-

opment and learning diﬃculties are lower than those in

D3.js. ECharts.js targets junior data analysts and software

developers with limited visualization knowledge and

experience, with its simple and user-friendly APIs mak-

ing it the easiest to use among the three libraries. e fol-

lowing versions were used in this study: version 5.16.0 for

D3.js, released in April 2020; version 5.4.2 for ECharts.js,

released in May 2023; and version 4.8.7 for G6.js, released

in February 2023.

Because the rendering method considerably aﬀects

graph visualization eﬃciency, it is stipulated that the

experimental unit is a pair of a web-based graph visuali-

zation library and one of its supported rendering meth-

ods. ECharts.js and G6.js supported the SVG and Canvas

methods, whereas D3.js supported the SVG, Canvas,

and WebGL methods. Consequently, seven experimen-

tal library entries were obtained: D3-SVG, D3-Canvas,

D3-WebGL, ECharts-SVG, ECharts-Canvas, G6-SVG,

and G6-Canvas. Notably, the use of native WebGL codes

to implement D3-WebGL is diﬃcult. Developers gener-

ally adopted additional libraries (i.e., NetV.js or ree.

js) to achieve the WebGL rendering part in D3.js. e

authors selected NetV.js (version v1.1.11 released in May

2023) [14] for the experiment because it was designed for

large-scale graph visualization.

Experimental library parameter conguration

Libraries are used to generate the node-link visualiza-

tions required to conﬁgure the node/edge style, canvas,

and layout algorithm parameters.

For the node/edge style parameters, the authors set the

node diameter and edge width of each library to 1 pixel.

e nodes and edges have no borders or text labels. For

the canvas parameter, they set the width and height of

the canvas to 3k

3k pixels.

For the layout algorithms, each library used its default

force-directed layout algorithm and parameter values.

e main parameter values are as follows: strength, theta,

alphaDecay, and alphaMin with values of -30, 0.9, 0.0228,

and 0.001 for the D3-SVG, D3-Canvas, and D3-WebGL

libraries, respectively. For the G6-SVG and G6-Can-

vas libraries, the main parameters included node/edge

strength, alpha, alphaDecay, and alphaMin, with param-

eter values of null, 0.3, 0.028, and 0.001, respectively.

For the ECharts-SVG and ECharts-Canvas libraries, the

main parameters included repulsion, gravity, and friction,

with parameter values of 50, 0.1, and 0.6, respectively.

For the layout algorithm iteration count, the authors set

the parameter value for each library to 200 times. is

parameter determines the number of iterations a layout

algorithm performs before stopping the computation.

Empirically, 200 iterations yield relatively stable lay-

out results. To reduce the length of the paper, detailed

parameters are provided in the Supplementary Material.

Graph dataset

e dataset selection for this experiment was based on

three considerations: (1) it should cover a wide range

of node scales, (2) cover a various edge scales, and (3)

involve diverse graph types.

e node scales of the experimental graph datasets

ranged from 100 to 200k, covering most application sce-

narios of node-link diagrams. Pilot experiments indicated

that WebWorker multithreading or GPU-based paral-

lel computing was required to generate the node-link

visualization of a graph with more than 200k nodes on a

mainstream desktop computer within a short time. e

authors divided the range of node scales into 47 levels

with four progressive intervals. Speciﬁcally, 10 node-scale

levels were set from 100 to 1k nodes with a ﬁxed interval

of 100 nodes; 9 node-scale levels were set from 1k to 10k

nodes with an interval of 1k nodes; 18 node-scale levels

were set from 10k to 100k nodes with an interval of 5k

nodes; and 10 node-scale levels were set from 100k to

200k nodes with an interval of 10k nodes. is division

method can obtain ﬁne-grained experimental results for

small- and medium-sized graphs commonly encoun-

tered by most users, whereas coarse-grained experimen-

tal results for uncommon large-sized graphs reduce the

computational burden.

e edge scale of the experimental graph dataset was

measured using the edge-to-node ratio (i.e., the number

of edges divided by the number of nodes). Ten edge-scale

levels were set from 1 to 10 edge-to-node ratios at ﬁxed

intervals for two reasons. First, users typically regard the

number of nodes, instead of the number of edges, as the

main consideration for the size of a graph dataset. ere-

fore, the authors stipulated that the number of nodes and

edge-to-node ratio would be the primary and second-

ary variables in determining the size of an experimental

graph dataset, which is consistent with user habits and

could also simplify the experimental design. Second, the

edge-to-node ratio is an important metric for distin-

guishing diﬀerent network types. For example, the edge-

node ratios of sparse networks [44] (e.g., transportation,

biological, and logistics networks) and small-world net-

works [45] (e.g., brain networks, power grids, and social

networks) are approximately 1 and 3, respectively. e

edge-node ratios of scale-free networks [46] (e.g., social

networks, internet topology, and scientiﬁc collabora-

tion networks) range from 1 to 5, with a few reaching 6

to 10 and very few exceeding 10 [47]. erefore, using

Page 5 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

the edge-to-node ratio and 10 edge-scale levels can help

users understand the eﬃciency advantages of graph visu-

alization libraries from the perspective of network types.

Each pair of a node-scale level and an edge-to-node

ratio had a corresponding graph dataset. In total, 470

datasets were established (47 node-scale levels

edge-to-node ratios). Moreover, the authors used CGs

and created a CG dataset for each of the 11 node-scale

levels, ranging from 100 to 2k nodes. Pilot experiments

demonstrated that CGs exceeding 2k nodes would have

over ten million edges, making it extremely diﬃcult to

generate visualizations on a mainstream desktop com-

puter in a short time. Consequently, 481 graph datasets

were established. Among them, 156 were sourced from

real-world networks, including social, citation, biologi-

cal, and internet networks. Relevant public repositories

include network repositories, UCI network data reposi-

tories, Pajek datasets, and the Stanford SNAP repository

[48–51]. e authors ﬁne-tuned 114 of the 156 real-world

network datasets and manually synthesized 325 datasets

to ensure that each node-scale level and edge-to-node

ratio pair contained one dataset. Additionally, the node-

link diagrams generated from each dataset were simple

graphs with attribute-free, content-agnostic edges and

nodes. ey utilized the Python NetworkX library [52] to

synthesize datasets, which oﬀered ﬂexible functions and

parameters (including the target node scale and edge-to-

node ratio) to generate desired graph datasets.

Apparatus

A mainstream desktop computer was used to ensure the

universality of the experimental results. e computer

ran on the Windows 10 operating system, equipped with

12th

GEN Intel(R)

CoreTM

i7-12700 CPU @ 2.10GHz

processor, 32.0GB of RAM, NVIDA GeForce RTX 3060,

and a Samsung SSD 980 1TB hard drive. e authors

used the Chrome browser version 106.0.5249.119 for the

experiments.

Procedure

e authors created a script to visualize each experimen-

tal dataset sequentially using each experimental library

three times. ey then recorded the time cost and frame

rate for each visualization. e time cost is the time

required to load a dataset into a library until 200 itera-

tions of layout computing and rendering are completed.

e authors recorded the overall time cost of graph visu-

alization rather than the time cost for individual techni-

cal steps. is decision was based on the fact that end

users often treat these libraries as a “black box” and are

primarily concerned with how quickly the ﬁnal visu-

alization can be generated. For the D3-SVG, D3-Canvas,

and D3-WebGL libraries, the time cost was measured

by recording the time required for 200 tick events. For

G6-SVG and G6-Canvas, the time diﬀerence between

beforeRender and afterRender events was calculated.

e time cost for the ECharts-SVG and ECharts-Canvas

libraries was measured by recording the time required

for 200 rendered events. Frame rate is the number of

visualization images displayed per second in a browser.

Each image was produced when a graph layout iteration

and graph rendering cycle were completed. e frame

rate was obtained using the browser’s requestAnimation-

Frame function. e maximum acceptable time to obtain

graph visualization was 15 min. e time cost and frame

rate results of a pair of datasets and libraries that failed to

complete 200 iterations of layout computing and render-

ing within 15 min were discarded.

Analysis approach

e raw experimental results were the raw time cost and

raw frame rate recorded to obtain a visualization using

each pair of graph dataset and graph visualization library.

In total, 10,101 raw time costs and 10,101 raw frame rates

(481 datasets

7 libraries

3 times) were collected. e

authors conducted a set of statistical computations on

the raw results to facilitate subsequent analyses. Tables1

and 2 summarize some statistical computations results.

Additional results are provided in the Supplementary

Materials.

For the raw time cost results, the average value of the

three raw time costs recorded when visualizing a data-

set using a library three times was computed. Table 1

summarizes the computation results for visualizing 481

datasets using the D3-SVG library. e cell in the second

row and second column of Table1 indicates that 3.6 s

were spent when visualizing a dataset with a node scale

of 200 (i.e., 200 nodes) and an edge-node ratio of 2 (i.e.,

400 edges) using the D3-SVG library three times. Moreo-

ver, some cells had ‘null’ values, indicating that the cor-

responding dataset could not be visualized within 15 min

using the D3-SVG library. Furthermore, CGs were only

involved at node scales ranging from 100 to 2k nodes.

erefore, cells exceeding 2k nodes in the CG column

were set with a gray background.

For the raw frame rate results, the authors computed

the average value of the frame rates recorded when visu-

alizing a dataset using a library three times. Table2 dis-

plays the computation results for visualizing 481 datasets

using the D3-SVG library. e cell in the second row and

tenth column of Table2 indicates that an average frame

rate of 55.8 fps was obtained for visualizing a dataset with

a node scale of 200 (i.e., 200 nodes) and an edge-to-node

ratio of 10 (i.e., 2k edges) using the D3-SVG library three

times. To reduce the paper length, the frame rate results

Page 6 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

of the other edge-to-node ratios are provided in the Sup-

plementary Material.

e results of the statistical analysis are presented in

various line-chart diagrams, as shown in Figs.1, 2, 3 and

4.Figure 1 has four line-chart diagrams. Each diagram

was drawn using the time cost results of all the libraries

with all the node scales and a speciﬁc edge-to-node ratio.

e edge-to-node ratios of the four diagrams were set

to 1, 5, 10, and CG, respectively. e four edge-to-node

ratios were selected for two reasons. First, the four edge-

to-node ratios can represent typical low, mid, high, and

CG graph densities. ey frequently occur in four com-

mon network types: scale-free, small-world, dense, and

complete. Second, this selection can help shorten the

duration of the study. e time cost results for the other

edge-to-node ratios are provided in the Supplementary

Material. For instance, the blue-colored lines in Fig.1a

andb depict the changing trends of time costs of using

the D3-SVG library to visualize the graph datasets when

the node scales of the datasets increase from 100 to 200k

and the edge-to-node ratios are ﬁxed at 1 and 5. e two

lines were drawn using the time costs recorded in the ﬁrst

and ﬁfth columns of Table1. Notably, the blue D3-SVG

line in Fig.1a starts at a minimum node scale of 100 and

ends at a maximum node scale of 200k. e blue D3-SVG

line in Fig.1b starts at the node scale 100 but ends at

110k because ‘null’ values occur in the ﬁfth column of

Table 1. Time cost results of visualizing the 481 graph datasets (47 node-scale levels

10 edge-to-node ratios + 11 node-scale levels

1 special edge-to-node ratio of CG) using the D3-SVG library

A cell corresponds to the average time cost of visualizing the graph dataset three times. The row of the cell represents the node-scale of the dataset. The column of

the cell represents the edge-to-node ratio of the dataset

Page 7 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

Table1 when the node scales exceed 110k, indicating that

the D3-SVG library cannot visualize datasets larger than

110k nodes within 15 minutes at the edge-to-node ratio

of 5 in the experiment.

Figure 2 has two line-chart diagrams. Figure 2a was

drawn using the time cost results of all libraries with all

the node scales by considering all edge-to-node ratios

(excluding CG) at the node scale as a whole. For example,

a point on the blue line in Fig.2a represents the average

value of the 10 time costs recorded in a row of Table1,

reﬂecting the D3-SVG’s average time cost for visualizing

the ten graph datasets with the edge-to-node ratios from

1 to 10 at a speciﬁc node scale. e blue line shows the

overall trend in time costs for using the D3-SVG library

to visualize graph datasets as the node scales increase

from 100 to 200k, with each node scale incorporating all

10 edge-to-node ratios. e blue D3-SVG line starts at

a node scale of 100 but ends at 70k because ‘null’ values

occur in Table1 when the node scales exceed 70k. us,

the authors cannot accurately assess the overall time

performance of the D3-SVG library at any node scale

exceeding 70k by considering the edge-to-node ratios

from 1 to 10.

Figure2b was drawn using the time cost results of all

libraries with all edge-to-node ratios (excluding CG) by

considering node scales from 100 to 10k as a whole. For

instance, the blue line in Fig.2b depicts the changing

trend of the time costs of the D3-SVG library when the

Table 2 Frame rate results of visualizing the 481 graph datasets (47 node-scale levels

10 edge-to-node ratios + 11 node-scale levels

1 special edge-to-node ratio of CG) using the D3-SVG library

A cell corresponds to the average frame rate of visualizing a graph dataset three times. The row of the cell represents the node scale of the dataset. The column of the

cell represents the edge-to-node ratio of the dataset

Page 8 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

edge-to-node ratios increased from 1 to 10, and each

edge-to-node ratio involved node scales ranging from

100 to 10k. A point on the line denotes the weighted

average value of the ﬁrst 19 time costs recorded in a

column of Table1. e selected node-scale range and

the weighted average value computation were carefully

considered to generate the ﬁgure. e node scale range

from 100 to 10k was chosen to facilitate a fair compar-

ison because all the libraries obtained valid time cost

results (i.e., no ‘null’ values) in this range. e weighted

average value computation was owing to the uneven

intervals of the selected node scale range. When gener-

ating the experimental datasets, the interval of the node

scales from 100 to 1k was set to 100, and the interval

of the node scales from 1k to 10k was set to 1k. us,

when calculating that the 10 time costs the obtained by

the node scales from 100 to 1k had a weight of 0.01 and

the nine time costs obtained by the node scales from 2k

to 10k had a weight of 0.1 when calculating the average

value of the ﬁrst 19 time costs recorded in a column of

Table1.

Figure 3 has four line-chart diagrams drawn using

the manner similar to the four diagrams in Fig.1. e

main diﬀerence is that the y-axis represents the frame

rate in Fig.3 but the time cost in Fig.1. at is, the four

diagrams in Fig.4 were drawn based on the frame rate

results in Table2. Additional frame rate results are pro-

vided in the Supplementary Material. Similarly, Fig.4

has two line-chart diagrams drawn in a manner simi-

lar to the two diagrams in Fig.2. e main diﬀerence

is that the y-axis represents the frame rate in Fig.4 but

the time cost in Fig.2.

Fig. 1 Line-chart visualizations of time cost results of all the libraries with all the node scales and edge-to-node ratios of 1 (a), 5 (b), 10 (c), and CG

(d). In each line-chart diagram, the x-axis denotes the node scale, y-axis denotes the time cost, a colored line represents a library, a point on a line

represents the time cost of visualizing a dataset using a library, and the top-right sub-diagram is the zoom-in view of the area of node scales

from 100 to 6k

Page 9 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

Results

Time cost result analysis

is subsection analyzes the time cost results of the

seven experimental library entries with an increase

in the node scales and edge-to-node ratios based on

Figs.1 and 2.

Figure 1 has four line-chart diagrams that pre-

sent the time cost results at the edge-to-node ratios

of 1, 5, 10, and CG, respectively. Figure1a uses seven

colored lines to depict the time cost changing trends

of the seven experimental libraries as the node scale

increases at an edge-to-node ratio of 1. e following

three main ﬁndings were obtained. (1) e lines begin

at the same node scale of 100 but end at diﬀerent node

scales, including ECharts-SVG at 25k, ECharts-Canvas

at 25k, G6-SVG at 65k, G6-Canvas at 150k, D3-SVG

at 200k, D3-Canvas at 200k, and D3-WebGL at 200k.

is indicates that the maximum node scale at which

each library could obtain graph visualizations within 15

min diﬀers at the edge-to-node ratio of 1. (2) e lines

exhibit approximately linear growth trends with diﬀer-

ent slopes. e D3-SVG, D3-Canvas, and D3-WebGL

lines present gentle slopes, indicating slow growth in

time costs. G6-SVG and G6-Canvas present medium

slopes, indicating moderate growth in time costs,

whereas ECharts-SVG and ECharts-Canvas present

steep slopes, indicating the rapid growths of time costs.

(3) e lines align closely within node scales from 100

to 3k; however, they diverge rapidly starting from the

node scale of 3k, as depicted in the local zoom-in view

at the top right of Fig.1a. is phenomenon indicates

that a node scale of 3k is the turning point. e time

costs of the libraries are close before this point but are

distinguished after it.

ese ﬁndings could be attributed to three main fac-

tors. (Factor 1) Graph layout algorithms. D3, ECharts,

and G6 libraries use diﬀerent variants of force-directed

layout algorithms, resulting in diﬀerent computational

time costs for graph layout generations. According to

the oﬃcial documentations of the libraries, D3 uses the

Barnes-Hut method [53] to accelerate the computational

process of repulsive forces; however, ECharts and G6 do

not mention such an optimization. erefore, D3 gener-

ally exhibited a better time performance than ECharts

and G6 in the graph layout algorithms. (Factor 2) Graph

rendering mechanisms. SVG, Canvas, and WebGL diﬀer

primarily in terms of their rendering mechanisms. SVG,

a vector graphic-based rendering mechanism, relies on

the document object model (DOM) to convert graphic

elements into pixels, leading to relatively long render-

ing times owing to DOM maintenance [35]. Canvas, a

resolution-dependent bitmap rendering mechanism,

directly renders graphics at ﬁxed pixel resolutions and

provides moderate rendering times by avoiding DOM

maintenance [36]. WebGL, an evolution of Canvas, uses

a GPU to manage the rendering pipeline and process the

rendering tasks in parallel, with relatively short rendering

times [24]. (Factor 3) Library building methods. D3 is a

low-level encapsulated library [10] that allows the direct

deﬁnition of graphic element properties, styles, and tran-

sitions, presenting a short workﬂow for controlling graph

elements. ECharts and G6 are high-level encapsulated

Fig. 2 a Line-chart visualization of time cost results of all the libraries with the node scales from 100 to 200k. The x-axis denotes the node scale,

y-axis denotes the time cost, a colored line represents a library, a point on a line represents the average time cost of visualizing the ten graph

datasets (corresponding to the ten edge-to-node ratios from 1 to 10, respectively) at a node scale, and the top-right sub-diagram is the zoom-in

view of the area of node scales from 100 to 10k; b Line-chart visualization of time cost results of all the libraries with the edge-to-node ratios

of 1–10. The x-axis denotes the edge-to-node, y-axis denotes the time cost, a colored line represents a library, and a point on a line represents

the weighted average time cost of visualizing the 19 graph datasets (corresponding to the 19 node scales from 100 to 10k) at an edge-to-node ratio

Page 10 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

libraries [11, 12] that use built-in functions and input

parameters to deﬁne graphical elements. Such high-level

encapsulation reduces programming complexity; how-

ever, it leads to a long inner-library workﬂow. erefore,

generating node-link visualizations using D3 generally

requires less time.

e authors further analyze the results presented in

Fig. 1a based on the three factors. D3-SVG exhibits

shorter time costs than G6-SVG and ECharts-SVG, and

D3-Canvas exhibits shorter time costs than G6-Canvas

and ECharts-Canvas, as indicated by the gentle slopes

and large ending node scales of D3-SVG and D3-Canvas.

is is mainly because D3 adopts a force computation

optimization and a low-level encapsulation method, as

mentioned in Factors 1 and 3. D3-Canvas and G6-Can-

vas have shorter time costs than D3-SVG and G6-SVG.

is result can be explained by Factor 2: Canvas gener-

ally requires shorter rendering times than SVG; however,

ECharts-SVG and ECharts-Canvas have close time costs

because ECharts uses virtual DOM to accelerate SVG

rendering. Moreover, D3-Canvas has slightly shorter time

costs than D3-WebGL; however, Factor 2 indicates that

WebGL commonly presents a better time performance

than Canvas. is is because the time performance

advantage of WebGL is not easily apparent when only

a few graphic elements for rendering are available at a

small edge-to-node ratio. is advantage is evident in the

time cost results at high edge-to-node ratios, as shown in

Fig.1b,c, andd.

Figure1b andc show the time cost results of the seven

experimental libraries at edge-to-node ratios of 5 and 10,

respectively. e three ﬁndings presented in Fig. 1a still

exist; however, a few new details can be found in the com-

parison. (1) e lines of ECharts-SVG, G6-SVG, G6-Can-

vas, and D3-SVG end at smaller node scales. (2) e line

slopes of the libraries increase to diﬀerent extents. (3) e

turning point for the time costs of libraries changes from

3k to 1k nodes. All the new details are owing to the higher

Fig. 3 Line-chart visualizations of frame rate results of all the libraries with all the node scales and edge-to-node ratios of 1 (a), 5 (b), 10 (c), and CG

(d). In each line-chart diagram, the x-axis denotes the node scale, the y-axis denotes the frame rate, a colored line represents a library, a point

on a line represents the frame rate of visualizing a dataset using a library, and the top-right sub-diagram is the zoom-in view of the area of node

scales from 100 to 10k

Page 11 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

edge-to-node ratios. e number of edges increases signiﬁ-

cantly, resulting in more time costs in generating graph lay-

outs and rendering graphic elements.

Figure1d shows the time cost results of the seven experi-

mental libraries at the edge-to-node ratio of CG. e

extremely increased number of edges increases the time

performance diﬀerences of the libraries. e slopes of the

seven lines are clearly distinguishable. D3-WebGL presents

the best time cost result with a superior force computation

optimization and a low-level encapsulation from D3 and

a higher performance graph rendering mechanism from

WebGL. G6-SVG presents the worst time cost result with

inferior force computation optimization, high-level encap-

sulation from G6, and lower performance graph rendering

mechanisms from SVG.

Figure2a uses seven colored lines to depict the overall

changing trends of the time cost for the seven experimental

libraries as the node scale increases, incorporating edge-to-

node ratios from 1 to 10 as a whole. e lines start at the

same node scale of 100 but end at diﬀerent node scales and

show approximately linear growth with diﬀerent slopes. A

line with a slower slope and a larger end node scale indi-

cates better time cost performance for the corresponding

library. e comparative results are as follows: D3-WebGL

> D3-Canvas > D3-SVG > G6-Canvas > ECharts-Canvas

≈

ECharts-SVG > G6-SVG.

Figure2b uses seven colored lines to depict the overall

changing trends in time cost for the seven experimental

libraries as the edge-to-node ratio increases, incorporat-

ing node scales from 100 to 10k nodes. e seven lines

exhibit approximately linear growth trends with diﬀerent

slopes. A line with a slower slope indicates better time

cost performance for the corresponding library as the

edge-to-node ratio increases. e comparative results

are as follows: D3-WebGL

≈

D3-Canvas > D3-SVG

> ECharts-Canvas > G6-Canvas

≈

ECharts-SVG >

G6-SVG.

Frame rate results analysis

is subsection analyzes the frame rate results of the

seven experimental library entries with increasing node

scales and edge-to-node ratios based on Figs.3 and 4.

Figure3 has four line-chart diagrams that present the

frame rate results of the seven experimental libraries at

the edge-to-node ratios of 1, 5, 10, and CG, respectively.

For analytical purposes, the authors stipulate that a frame

rate exceeding or below 30 fps is called a high or low

frame rate, because 30 fps is the minimum frame rate

necessary for smooth human-vision perception [20].

Figure3a uses seven colored lines to depict the chang-

ing trends in the frame rates of the experimental librar-

ies as the node scale increases at an edge-to-node ratio

of 1. Two main ﬁndings are presented in Fig.3a. First, the

lines present diﬀerent changing trends in diﬀerent node

scale ranges. At small node scales, all the lines maintain

high frame rates. After reaching certain node scales,

the lines of D3-Canvas and D3-WebGL exhibit gentle

declines, whereas those of the other ﬁve libraries exhibit

rapid declines. As the node scale increases further, all the

lines decline slowly, approaching zero fps. Second, each

Fig. 4 a Line-chart visualization of frame rate results of all the libraries with the node scales from 100 to 200k. The x-axis denotes the node scale,

the y-axis denotes the frame rate, a colored line represents a library, a point on a line represents the average frame rate of visualizing the ten graph

datasets (corresponding to the ten edge-to-node ratios from 1 to 10, respectively) at a node scale, and the top-right sub-diagram is the zoom-in

view of the area of node scales from 100 to 10k; b Line-chart visualization of frame rate results of all the libraries with the edge-to-node ratios from 1

to 10. The x-axis denotes the edge-to-node, the y-axis denotes the frame rate, a colored line represents a library, and a point on a line represents

the weighted average frame rate of visualizing the 19 graph datasets (corresponding to the 10 node scales from 100 to 10k) at an edge-to-node

ratio

Page 12 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

line has a diﬀerent maximum node scale for obtaining

high frame rates called HFR-MaxNS in the latter. e

HFR-MaxNSs of G6-SVG, G6-Canvas, ECharts-SVG,

D3-SVG, ECharts-Canvas, D3-Canvas, and D3-WebGL

are 600, 1k, 2k, 2k, 3k, 5k, and 7k, respectively.

e two main ﬁndings can be explained by the factors

summarized in Fig.1a. D3 adopts a force computation

optimization (Factor 1) and a low-level encapsulation

(Factor 3). WebGL and Canvas adopt higher-perfor-

mance graph rendering mechanisms than SVG (Factor 2).

erefore, D3-WebGL and D3-Canvas present the best

frame rate results, as indicated by the slowest declines

and maximum HFR-MaxNSs of the D3-WebGL and

D3-Canvas lines compared with the other ﬁve lines in

Fig.3a. Additionally, the authors observe in Fig.3a that

D3-SVG obtains better frame rate results than G6-SVG

and ECharts-SVG, G6-Canvas has better frame rate

results than G6-SVG, and ECharts-Canvas has better

frame rate results than ECharts-SVG.

Two interesting phenomena were observed. (1) e

frame rate of D3-WebGL (50 fps) was lower than that

of the other ﬁve libraries (60 fps) at a minimum exam-

ined node scale of 100. e initialization process of

WebGL includes two special operations: shader compi-

lation and buﬀer management, which lowers the frame

rate at the initialization stage. (2) e frame rate results

of the two ECharts libraries are superior to those of the

two G6 libraries; however, the time cost results of the

two ECharts libraries are inferior to those of the two G6

libraries. is is mainly because ECharts supports a pro-

gressive visualization mechanism to ensure the rendering

of a limited number of graphic elements in each frame.

Figure3b,c, andd show the frame rate results of the

seven experimental libraries as the node scale increases

at edge-to-node ratios of 5, 10, and CG, respectively.

e two main ﬁndings obtained in Fig. 3a still exist;

however, new details can be found in the comparison.

(1) e lines in the three ﬁgures decline more rapidly

than the lines in Fig.3a. (2) e HFR-MaxNS of each

library decreases. In Fig.3b,c, andd, the HFR-MaxNSs

of D3-WebGL are at 6k, 5k, and 700, respectively;

those of D3-Canvas are at 4k, 2k, and 200, respectively;

those of D3-SVG are at 1k, 600, and 100, respectively;

those of ECharts-Canvas are at 2k, 2k, and 200, respec-

tively; and those of ECharts-SVG are at 1k, 700, and

100, respectively. In Fig. 3b and c, the HFR-MaxNSs

of G6-SVG are 200 and 100, respectively, and 300 and

200, respectively, for G6-Canvas. However, as shown in

Fig.3d, G6-SVG and G6-Canvas did not achieve high

frame rates at the minimum node scale examined in

the experiment. ese new features are related to an

increase in the edge-to-node ratio. A large increase

in the number of edges deteriorates the rendering

performance of all the libraries. Moreover, the render-

ing advantage of WebGL using GPU’s parallel processes

becomes increasingly apparent as the edge-to-node

ratio increases. us, at edge-to-node ratios of 5, 10,

and CG, the rendering performance of D3-WebGL is

superior to that of the other libraries.

Figure4a uses seven colored lines to depict the overall

changing trends of the frame rate for the seven libraries

as the node scale increases, incorporating edge-to-node

ratios from 1 to 10. e lines present approximately

nonlinear declining trends at diﬀerent speeds and

end at diﬀerent node scales. A line that declines more

slowly and ends at a larger node scale indicates a better

frame rate performance for the corresponding library

as the node scale increases. e comparative results are

as follows: D3-WebGL > D3-Canvas > ECharts-Canvas

> ECharts-SVG

≈

D3-SVG > G6-Canvas > G6-SVG.

Figure4b uses seven colored lines to depict the overall

changing trends in the frame rate for the seven experi-

mental libraries as the edge-to-node ratio increases,

incorporating node scales from 100 to 10k nodes. e

seven lines exhibited approximately linear declining

trends with diﬀerent slopes. A line with a slower slope

indicates better frame rate performance for the corre-

sponding library as the edge-to-node ratio increases.

e comparative results are as follows: D3-WebGL >

D3-Canvas > ECharts-Canvas > ECharts-SVG > D3-SVG

> G6-Canvas>G6-SVG.

Application‑oriented guidance andusage cases

e previous two subsections oﬀer an in-depth analysis

of the time cost and frame rate results. However, these

analyses are not user-friendly in providing application-

oriented guidance to end users when selecting a web-

based graph visualization library based on eﬃciency

requirements. e experimental results are summarized

in Tables3 and 4. e authors also provide three usage

cases that incorporate the three main factors end users

considered when choosing libraries to demonstrate how

to apply the results in the tables.

Table3 summarizes the maximum node scales of graph

datasets on which each experimental library can gener-

ate node-link visualizations within three given time limits

(i.e., 15-, 5-, and 1-min) at edge-to-node ratios ranging

from 1 to 10. e three-time limits correspond to the

maximum acceptable, common, and optimal time costs,

respectively. Table 3 serves as a quick reference of the

time cost results obtained in the experiment for practical

use. For example, the cell in the ﬁrst row and ﬁrst column

indicates that D3-SVG visualizes a graph dataset with an

edge-to-node ratio of 1. Within 15 min, the maximum

node scale of the graph dataset is 200k nodes. e cell in

the 20th row and 7th column indicates that the maximum

Page 13 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

node scale that can be visualized using G6-SVG within 5

minat an edge-to-node ratio of 10 is 4k nodes.

Table4 summarizes the maximum node scales of graph

datasets on which each experimental library can gener-

ate node-link visualizations while maintaining a frame

rate above 30 fps or 10 fps at edge-to-node ratios ranging

from 1 to 10. irty fps is the minimum frame rate neces-

sary for smooth human vision perception, whereas 10 fps

is the empirical threshold below which human eyes can

detect stuttering in animations. Table4 serves as a quick

reference of the frame rate results obtained in the experi-

ment for practical use. For example, the cell in the ﬁrst

row and column indicates that when using D3-SVG to

visualize a graph dataset with an edge-to-node ratio of 1

and a frame rate above 30 fps, the maximum node scale of

the graph dataset is 2k nodes. e cell in the 20th row and

7th column indicates that the maximum node scale that

can be visualized using G6-SVG with a frame rate above

10 fps at an edge-to-node ratio of 10 is 300 nodes.

ree usage cases are considered to demonstrate how

to use the results in Tables3 and 4.

Alan, a front-end engineer, is developing a web appli-

cation for social network data analysis. e web applica-

tion requires the generation of node-link visualizations

using social network data with less than 2k nodes and an

edge-to-node ratio of approximately 1. End users of the

web application may interact with node-link diagrams

through actions such as dragging and selecting nodes,

which require smooth animation. erefore, Alan’s

Table 3 Application-oriented time cost results

The row represents the time limit (15, 5, or 1 min) and the edge-to-node ratio (ranging from 1 to 10).The column of the cell represents the library. A cell corresponds

to the maximum node scale of a graph dataset that can be visualized within a specic time limit and at a specic edge-to-node ratio

Time limit

(min) Edge‑to‑node

ratio D3‑SVG D3‑Canvas D3‑WebGl ECharts‑

Canvas ECharts‑SVG G6‑Canvas G6‑SVG

15 1 200k 200k 200k 25k 25k 150k 65k

2 180k 200k 200k 25k 25k 95k 40k

3 140k 200k 200k 25k 25k 70k 30k

4 130k 200k 200k 25k 20k 55k 25k

5 110k 200k 200k 25k 20k 45k 20k

6 100k 200k 200k 25k 20k 40k 20k

7 85k 200k 200k 25k 20k 30k 15k

8 75k 200k 200k 25k 20k 30k 15k

9 70k 200k 200k 25k 20k 25k 10k

10 70k 200k 200k 25k 20k 25k 10k

5 1 90k 200k 180k 10k 10k 60k 25k

2 65k 180k 180k 15k 10k 30k 15k

3 50k 160k 180k 10k 10k 20k 10k

4 45k 140k 180k 15k 10k 15k 10k

5 40k 130k 170k 15k 10k 15k 8k

6 35k 110k 170k 10k 10k 10k 7k

7 25k 100k 160k 10k 10k 10k 6k

8 25k 100k 160k 10k 10k 10k 5k

9 20k 85k 150k 10k 10k 9k 5k

10 20k 85k 150k 10k 9k 9k 4k

11 20k 50k 55k 6k 6k 10k 5k

2 10k 45k 55k 6k 5k 6k 3k

3 10k 30k 50k 6k 4k 5k 2k

4 10k 30k 50k 6k 4k 4k 2k

5 9k 25k 50k 6k 4k 3k 1k

6 7k 20k 50k 5k 3k 2k 1k

7 6k 20k 50k 5k 3k 2k 1k

8 6k 20k 45k 5k 3k 2k 1k

9 5k 20k 45k 5k 2k 2k 1k

10 5k 15k 45k 5k 2k 1k 1k

Page 14 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

eﬃciency requirements can be summarized as generating

node-link visualizations of social network data with 2k

nodes and an edge-to-node ratio of 1 within 1 minwhile

maintaining a frame rate above 30 fps. Additionally, Alan

requires a visualization library with low programming

complexity to enhance development eﬃciency.

Considering the eﬃciency requirements, Alan refers

to the 21st row in Table3. e results in this row indi-

cate that all libraries can visualize graph data with 2k000

nodes and an edge-to-node ratio of 1 within a 1-min

limit. ereafter, Alan refers to the ﬁrst row in Table4.

e results in this row indicate that D3-SVG, D3-Can-

vas, D3-WebGL, ECharts-SVG, and ECharts-Canvas can

visualize graph data with 2k nodes and an edge-to-node

ratio of 1 while maintaining the frame rate above 30 fps.

D3-SVG, D3-Canvas, D3-WebGL, ECharts-SVG, and

ECharts-Canvas satisﬁes Alan’s eﬃciency requirements

by intersecting the ﬁndings from Tables3 and 4. Addi-

tionally, considering the requirement of low program-

ming complexity, Alan prefers ECharts, which oﬀers a

high-level encapsulation of node-link visualization gen-

eration functions. erefore, considering both eﬃciency

and programming complexity, ECharts-Canvas and

ECharts-SVG are the desired library options for Alan to

develop the web applications.

Bob, a product architect, is designing a web application

for supply chain data analysis. e application requires

the generation of node-link visualization using supply

chain network data with a maximum node scale of 5k

and an edge-to-node ratio of approximately 5. e appli-

cation requires avoiding noticeable animation stutters.

erefore, Bob’s eﬃciency requirements can be sum-

marized as generating node-link visualizations of supply

chain graphs with 5k nodes and an edge-to-node ratio of

5 within 1 min while maintaining a frame rate above 10

fps. e results in the 25th row of Table3 indicate that

D3-SVG, D3-Canvas, D3-WebGL, and ECharts-Canvas

can visualize graph data with 5k nodes and an edge-

to-node ratio of 5 within 1 min. e results in the 15th

row of Table4 indicate that D3-Canvas and D3-WebGL

can maintain a frame rate above 10 fps while visualizing

graph data with 1k nodes and an edge-to-node ratio of 5.

By combining these results, D3-Canvas and D3-WebGL

satisfy Bob’s eﬃciency requirements.

Christy, a big data engineer, is working on a large-scale

graph analysis study. e study requires the genera-

tion of a node-link visualization of a graph dataset with

100k nodes and an edge-to-node ratio of approximately

10. Christy focuses on whether the visualization could

be generated within the maximum acceptable time limit

with no speciﬁc requirements for the frame rate. ere-

fore, Christy’s eﬃciency requirements can be summa-

rized as generating a node-link diagram using a graph

dataset with 100k nodes and an edge-to-node ratio of 10

within 15 min. As the results in the 10th row of Table3

indicated, both D3-Canvas and D3-WebGL satisfy

Christy’s eﬃciency requirements. Considering the need

to adopt one of the additional libraries to achieve the

WebGL rendering part in D3.js, which has higher pro-

gramming complexity compared to D3-Canvas. ere-

fore, Christy prefers D3-Canvas to complete the study.

Discussion

is section discusses the limitations of this study and

proposes directions for future work.

e scales and application scenarios of the graph data-

sets used in this study have limited coverage. e scales

were capped at 200k nodes. us, evaluating the perfor-

mance of web-based graph visualization libraries beyond

this scale is worth further investigation. e authors

anticipate that such evaluations will likely involve librar-

ies supporting the WebGL rendering method and require

advanced acceleration techniques such as WebWorker

programming and parallel computing [54, 55]. Addition-

ally, the application scenarios related to the datasets were

limited. e potential applications of node-link diagrams

are extensive, and include genomic research, neural net-

works, and infrastructure mapping [56–58]. However,

these scenarios were not included in the datasets. e

applicability of our ﬁndings to these scenarios remains

uncertain and warrants further investigation.

e number of graph visualization libraries was also

limited. Other libraries available on the market, such

as Cytoscape.js, Vis.js, and Sigma.js, were not included

[25, 59, 60]. Moreover, although stable versions of

D3.js, ECharts.js, and G6.js were selected, these librar-

ies have newly released versions, such as D3.js version

7.9.0, released in March 2024; ECharts.js version 5.5.1,

released in June 2024; and G6.js version 5.0.17, released

in August 2024. Further explorations that introduce addi-

tional libraries and compare the performance diﬀerences

across diﬀerent versions of the same library would also be

worthwhile.

e experiments in this study were conducted using

the default conﬁguration parameters for each library.

e parameters of these libraries can be further adjusted

using the results of this study. Fine-tuning the param-

eters may improve performance. e experiments were

conducted using speciﬁc hardware and software. How-

ever, the results may exhibit subtle variations in diﬀerent

experimental environments. Based on our experience,

adopting a more advanced GPU and multicore processor

with higher clock speeds for hardware, as well as using

the latest versions of graph visualization libraries and

optimizing browser settings for software, could further

Page 15 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

enhance the eﬃciency of the libraries. is warrants fur-

ther investigation.

e experiment measured the time cost as the dura-

tion from loading a dataset into a library to completing

200 iterations of layout computation and rendering. is

was chosen because common library users are primar-

ily concerned with the overall time required to visual-

ize a node-link diagram. From a technical perspective,

the layout computation and rendering processes involve

multiple technical steps, including initializing node posi-

tions, calculating forces between nodes, updating node

positions, drawing nodes and edges, rasterizing graphical

elements into pixels, and compositing the ﬁnal image. For

researchers and library developers, analyzing the time

performance of each step individually for experimental

libraries could provide insights into identifying perfor-

mance bottlenecks and facilitate the optimization of the

library. is should be further explored in future studies.

is study used NetV.js to implement the WebGL

rendering method. However, other WebGL implemen-

tations, such as the native WebGL API or ree.js [61],

could also be employed, which may result in diﬀer-

ent performance results that were not addressed in this

study. e impact of diﬀerent WebGL implementations

on the rendering performance should be explored in

future research.

e experimental results were based on static node-

link diagrams, where the number of nodes and edges

remained constant. is study does not cover dynamic

node-link diagrams, where nodes and edges can be

added or removed. e performance of diﬀerent librar-

ies in dynamic node-link diagrams is an important area

of investigation for future research [62].

Conclusions

is study investigates the node-link graph visualization

eﬃciency of popular web-based libraries. e authors

selected seven library entries: D3-SVG, D3-Canvas,

D3-WebGL, ECharts-SVG, ECharts-Canvas, G6-SVG,

and G6-Canvas, and prepared 481 graph datasets with

node scales ranging from 100 to 200k and edge-to-

node ratios from 1 to 10 (including CG) to conduct a

controlled experiment. ey recorded the time costs

and frame rates using libraries to visualize the data-

sets as the experimental results. After a theoretical and

empirical analysis of the results, they summarized the

overall trends and relative strengths of the eﬃciency per-

formance of the libraries and reorganized the results and

Table 4 Application-oriented frame rate results

The row represents the frame rate threshold (30 or 10 fps) and the edge-to-node ratio (ranging from 1 to 10).The column of the cell represents the library. A cell

corresponds to the maximum node scale of a graph dataset that can be visualized above a specic frame rate threshold and at a specic edge-to-node ratio

Frame rate

(fps) Edge‑to‑node

ratio D3‑SVG D3‑Canvas D3‑WebGl ECharts‑

Canvas ECharts‑SVG G6‑Canvas G6‑SVG

30 1 2k 5k 7k 3k 2k 1k 600

2 1k 5k 6k 2k 1k 800 300

3 1k 5k 5k 2k 1k 600 200

4 1k 4k 6k 2k 1k 300 200

5 1k 4k 6k 2k 1k 300 200

6 1k 3k 6k 2k 1k 300 100

7 800 3k 5k 2k 900 200 100

8 700 3k 5k 2k 800 200 100

9 600 2k 6k 2k 700 200 100

10 600 2k 5k 2k 700 200 100

10 1 7k 15k 20k 5k 4k 3k 2k

2 5k 15k 20k 5k 4k 2k 1k

3 4k 10k 20k 5k 3k 1k 900

4 3k 10k 20k 4k 3k 1k 700

5 3k 10k 20k 4k 3k 1k 600

6 2k 10k 20k 4k 2k 1k 500

7 2k 9k 20k 4k 2k 800 400

8 2k 9k 15k 4k 2k 700 400

9 2k 8k 15k 4k 2k 700 300

10 2k 9k 15k 4k 2k 600 300

Page 16 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

ﬁndings into application-oriented guidelines and three

usage cases to help end users quickly select the desired

libraries based on their speciﬁc eﬃciency requirements

of node-link graph visualizations. e authors hope that

this study oﬀers application-oriented perspectives on the

evolution of graph visualization techniques.

Abbreviations

API Application programming interface

fps Frames per second

SVG Scalable vector graphics

WebGL Web graphics library

GPU Graphics processing unit

CG Complete graph

DOM Document object model

HFR-MaxNS Maximum node scale for high frame rates

Supplementary Information

The online version contains supplementary material available at https:// doi.

org/ 10. 1186/ s42492- 025- 00193-y.

Supplementary Material 1.

Acknowledgements

Not applicable.

Authors’ contributions

XZ and YZ conceptualized the study, wrote the manuscript (including sub-

stantive translation); XW and XZZ conducted the experiment, analyzed the

experiment results; HML and GHB created visualization charts of the experi-

ment results; NZ and XH contributed information to the introduction and

study design; FFZ revised the manuscript; The ﬁnal manuscript has been read

and approved by all authors.

Funding

This work has been supported by the National Natural Science Foundation of

China, Nos. 62272480 and 62472444.

Data availability

The dataset supporting the conclusions of this article is included within the

article and its additional ﬁle.

Declarations

Competing interests

The authors declare that they have no competing interests.

Received: 18 November 2024 Accepted: 25 March 2025

References

1. Chen Y, Guan ZL, Zhang R, Du XM, Wang YH (2019) A survey on visualiza-

tion approaches for exploring association relationships in graph data. J

Vis 22(3):625–39. https:// doi. org/ 10. 1007/ s12650- 019- 00551-y

2. Zhao Y, Jiang HJ, Chen QA, Qin YQ, Xie HX, Wu YT et al (2021) Preserv-

ing minority structures in graph sampling. IEEE Trans Vis Comput Graph

27(2):1698–708. https:// doi. org/ 10. 1109/ TVCG. 2020. 30304 28

3. Zhao Y, Shi JC, Liu JW, Zhao J, Zhou FF, Zhang WZ et al (2022) Evaluating

eﬀects of background stories on graph perception. IEEE Trans Vis Comput

Graph 28(12):4839–54. https:// doi. org/ 10. 1109/ TVCG. 2021. 31072 97

4. Ghoniem M, Fekete JD, Castagliola P (2004) A comparison of the read-

ability of graphs using node-link and matrix-based representations. In:

Proceedings of the IEEE symposium on information visualization, IEEE,

Austin, 10–12. https:// doi. org/ 10. 1109/ INFVIS. 2004.1

5. Zhou ZG, Shi C, Shen XL, Cai LH, Wang HX, Liu YH et al (2021) Context-

aware sampling of large networks via graph representation learning. IEEE

Trans Vis Comput Graph 27(2):1709–19. https:// doi. org/ 10. 1109/ TVCG.

2020. 30304 40

6. Burch M, Brinke K, Castella A, Peters G, Shteriyanov V, Vlasvinkel R (2021)

Dynamic graph exploration by interactively linked node-link diagrams

and matrix visualizations. Vis Comput Ind Biomed Art 4(1):23. https:// doi.

org/ 10. 1186/ s42492- 021- 00088-8

7. Xiong WL, Yu CJ, Shi C, Zheng YX, Wang XP, Hu YP et al (2024) V4RIN: visual

analysis of regional industry network with domain knowledge. Vis Com-

put Ind Biomed Art 7(1):11. https:// doi. org/ 10. 1186/ s42492- 024- 00164-9

8. Kwon OH, Muelder C, Lee K, Ma KL (2016) A study of layout, rendering,

and interaction methods for immersive graph visualization. IEEE Trans Vis

Comput Graph 22(7):1802–15. https:// doi. org/ 10. 1109/ TVCG. 2016. 25209

9. Schulz C, Nocaj A, Goertler J, Deussen O, Brandes U, Weiskopf D (2017)

Probabilistic graph layout for uncertain network visualization. IEEE Trans

Vis Comput Graph 23(1):531–40. https:// doi. org/ 10. 1109/ TVCG. 2016.

25989 19

10. Bostock M, Ogievetsky V, Heer J (2011) D3 data-driven documents. IEEE

Trans Vis Comput Graph 17(12):2301–9. https:// doi. org/ 10. 1109/ TVCG.

2011. 185

11. Wang YY, Bai ZN, Lin ZF, Dong XQ, Feng YCJ, Pan JC (2021) G6: A web-

based library for graph visualization. Visual Inf 5(4):49–55. https:// doi. org/

10. 1016/j. visinf. 2021. 12. 003

12. Li DQ, Hui MH, Shen Y, Su S, Zhang WL, Wang JT (2018) Echarts: A declara-

tive framework for rapid construction of web-based visualization. Visual

Inf 2(2):136–46. https:// doi. org/ 10. 1016/j. visinf. 2018. 04. 011

13. Shahzad F, Sheltami TR, Shakshuki EM, Shaikh O (2016) A review of latest

web tools and libraries for state-of-the-art visualization. Procedia Comput

Sci 98:100–6. https:// doi. org/ 10. 1016/j. procs. 2016. 09. 017

14. Han DM, Pan JC, Zhao XD, Chen W (2021) NetV.js: A web-based library for

high-eﬃciency visualization of large-scale graphs and networks. Visual Inf

5(1):61–6. https:// doi. org/ 10. 1016/j. visinf. 2021. 01. 002

15. Eades P (1984) A heuristic for graph drawing. Congr Numerantium

42(42):149–60

16. Fruchterman TMJ, Reingold EM (1991) Graph drawing by force-directed

placement. Softw Pract Exp 21(11):1129–64. https:// doi. org/ 10. 1002/ spe.

43802 11102

17. Kobourov SG (2012) Spring embedders and force directed graph drawing

algorithms. arXiv:1201.3011 [cs.CG]. https:// doi. org/ 10. 48550/ arXiv. 1201.

3011

18. Jacomy M, Venturini T, Heymann S, Bastian M (2014) Forceatlas2, a con-

tinuous graph layout algorithm for handy network visualization designed

for the Gephi software. PLoS One 9(6):98679. https:// doi. org/ 10. 1371/

journ al. pone. 00986 79

19. Herman I, Melancon G, Marshall MS (2000) Graph visualization and navi-

gation in information visualization: a survey. IEEE Trans Vis Comput Graph

6(1):24–43. https:// doi. org/ 10. 1109/ 2945. 841119

20. Funkhouser TA, Séquin CH (1993) Adaptive display algorithm for interac-

tive frame rates during visualization of complex virtual environments.

In: Proceedings of the 20th annual conference on computer graphics

and interactive techniques, ACM, Anaheim, 2–6. https:// doi. org/ 10. 1145/

166117. 166149

21. Pavlopoulos GA, Paez-Espino D, Kyrpides NC, Iliopoulos I (2017) Empirical

comparison of visualization tools for larger-scale network analysis. Adv

Bioinformatics 2017(1):1278932. https:// doi. org/ 10. 1155/ 2017/ 12789 32

22. Lavanya A, Sindhuja S, Gaurav L, Ali W (2023) A comprehensive review of

data visualization tools: features, strengths, and weaknesses. Int J Comput

Eng Res Trends 1(10):10–20. https:// doi. org/ 10. 22362/ ijcert/ 2023/ v10/

i01/ v10i0 102

23. Gibson H, Faith J, Vickers P (2013) A survey of two-dimensional graph

layout techniques for information visualisation. Inf Vis 12(3-4):324–57.

https:// doi. org/ 10. 1177/ 14738 71612 455749

24. Leung C, Salga A (2010) Enabling WebGL. In: Proceedings of the 19th

international conference on world wide web, ACM, Raleigh, 26–30.

https:// doi. org/ 10. 1145/ 17726 90. 17729 33

Page 17 of 17

Zhaoetal. Visual Computing for Industry, Biomedicine, and Art (2025) 8:12

25. Coene JP (2018) Sigmajs: An R htmlwidget interface to the sigma.js

visualization library. J Open Source Software 3(28):814. https:// doi. org/ 10.

21105/ joss. 00814

26. Foundation O (2024) Chart.js documentation.https:// www. chart js. org/

docs/ latest. Accessed 12 Apr 2024

27. SAS L (2024) Linkurious.js. https:// linku rious. com. Accessed 12 Apr 2024

28. Zhou YX, Yang WK, Chen JS, Chen CJ, Shen ZY, Luo XN et al (2024) Cluster-

aware grid layout. IEEE Trans Vis Comput Graph 30(1):240–50. https:// doi.

org/ 10. 1109/ TVCG. 2023. 33269 34

29. Dogrusoz U, Belviranli ME, Dilek A (2013) CiSE: A circular spring embedder

layout algorithm. IEEE Trans Vis Comput Graph 19(6):953–66. https:// doi.

org/ 10. 1109/ TVCG. 2012. 178

30. Xu PF, Li YF, Yang ZJ, Shi WR, Fu HB, Huang H (2022) Hierarchical layout

blending with recursive optimal correspondence. ACM Trans Graph

41(6):249. https:// doi. org/ 10. 1145/ 35504 54. 35554 46

31. Harel D, Koren Y (2002) Graph drawing by high-dimensional embedding.

In: Goodrich MT, Kobourov SG (eds) Graph Drawing. 10th International

Symposium, GD 2002. Lecture Notes in Computer Science, vol 2528.

Springer, Berlin, Heidelberg, pp 207–19. https:// doi. org/ 10. 1007/3- 540-

36151-0_ 20

32. Brandes U, Pich C (2006) Eigensolver methods for progressive mul-

tidimensional scaling of large data. In: Kaufmann M, Wagner D (eds)

Graph Drawing. 14th International Symposium, GD 2006. Lecture

notes in computer science (Theoretical computer science and general

issues), vol 4372. Springer, Karlsruhe, pp 42–53. https:// doi. org/ 10. 1007/

978-3- 540- 70904-6_6

33. Zhu MF, Chen W, Hu YZ, Hou YX, Liu LJ, Zhang KY (2020) DRGraph: An

eﬃcient graph layout algorithm for large-scale graphs by dimensionality

reduction. IEEE Trans Vis Comput Graph 27(2):1666–76. https:// doi. org/ 10.

1109/ TVCG. 2020. 30304 47

34. Zhou FF, Li JC, Huang W, Zhao Y, Yuan XR, Liang X et al (2016) Dimension

reconstruction for visual exploration of subspace clusters in high-

dimensional data. In: Proceedings of the 2016 IEEE paciﬁc visualization

symposium, IEEE, Taipei, China, 19–22. https:// doi. org/ 10. 1109/ PACIF

ICVIS. 2016. 74652 60

35. Quint A (2003) Scalable vector graphics. IEEE MultiMedia 10(3):99–102.

https:// doi. org/ 10. 1109/ MMUL. 2003. 12182 61

36. Fulton S, Fulton J (2013) HTML5 Canvas: Native Interactivity and Anima-

tion for the Web, 2nd edn. O’Reilly Media, Inc., Sebastopolhttps:// doi. org/

10. 1016/ B978- 15586 0819-1/ 50001-7

37. Baek N, Lee H (2012) OpenGL ES 1.1 implementation based on

OpenGL. Multimed Tools Appl 57(3):669–85. https:// doi. org/ 10. 1007/

s11042- 010- 0662-4

38. Li W, Wang SS, Xie WD, Yu K, Feng CL (2023) Large scale medical image

online three-dimensional reconstruction based on WebGL using four tier

client server architecture. Inf Vis 22(2):100–14. https:// doi. org/ 10. 1177/

14738 71622 11380 90

39. Grandhi R, Reddy BVK, Guntupalli V, Natarajan P (2019) WebGL-based

game engine. In: Saini HS, Sayal R, Govardhan A, Buyya R (eds) Innova-

tions in Computer Science and Engineering. Proceedings of the Fifth

ICICSE 2017. Lecture notes in networks and systems. Springer, Singapore,

32:11–7. https:// doi. org/ 10. 1007/ 978- 981- 10- 8201-6_2

40. Zhang YJ (2018) Development of WebGL-based virtual teaching platform

for mold design. Int J Emerg Technol Learn 13(6):16–28. https:// doi. org/

10. 3991/ ijet. v13i06. 8581

41. Giri P, Chandra S, Chakraborty S, Choudhury PD (2023) Utilization of three.

js and unity to make a WebGL API to perform 3D immersiveness in web.

Am J Electron Commun 3(4):20–3. https:// doi. org/ 10. 15864/ ajec. 3405

42. Lu HL, Wu JX, Liu YS, Wang WQ (2019) Dynamically loading IFC models

on a web browser based on spatial semantic partitioning. Vis Comput Ind

Biomed Art 2(1):4. https:// doi. org/ 10. 1186/ s42492- 019- 0011-z

43. Gui S, Khan D, Wang Q, Yan DM, L BZ (2018) Frontiers in biomolecular

mesh generation and molecular visualization systems. Vis Comput Ind

Biomed Art 1(1):7. https:// doi. org/ 10. 1186/ s42492- 018- 0007-0

44. Singh A, Humphries MD (2015) Finding communities in sparse networks.

Sci Rep 5:8828. https:// doi. org/ 10. 1038/ srep0 8828

45. Watts DJ, Strogatz SH (1998) Collective dynamics of ‘small-world’ net-

works. Nature 393(6684):440–2. https:// doi. org/ 10. 1038/ 30918

46. Barabási AL (2009) Scale-free networks: a decade and beyond. Science

325(5939):412–3. https:// doi. org/ 10. 1126/ scien ce. 11732 99

47. Melançon G (2006) Just how dense are dense graphs in the real world?

a methodological note. In: Proceedings of the AVI workshop on BEyond

time and errors: novel evaluation methods for information visualization,

ACM, Venice, 23. https:// doi. org/ 10. 1145/ 11681 49. 11681 67

48. Rossi RA, Ahmed NK (2015) The network data repository with interac-

tive graph analytics and visualization. In: Proceedings of the 29th AAAI

conference on artiﬁcial intelligence, AAAI, Austin, 25–30. https:// doi. org/

10. 1609/ aaai. v29i1. 9277

49. Kelly M, Longjohn R, Nottingham K (2024) Welcome to the UC Irvine

Machine Learning Repository. https:// archi ve. ics. uci. edu. Accessed 12 Apr

2024

50. Batagelj V, Mrvar A (2004) Pajek-analysis and visualization of large net-

works. In: Jünger M, Mutzel P (eds) Graph Drawing Software. Mathemat-

ics and visualization. Springer, Berlin, Heidelberg, pp 77–103. https:// doi.

org/ 10. 1007/ 978-3- 642- 18638-7_4

51. Leskovec J, Sosič R (2016) SNAP: a general-purpose network analysis and

graph-mining library. ACM Trans Intell Syst Technol 8(1):1. https:// doi. org/

10. 1145/ 28983 61

52. Hagberg AA, Schult DA, Swart PJ (2008) Exploring network structure,

dynamics, and function using networkX. In: Proceedings of the 7th

Python in science conference, SciPy, California, 19–24. https:// doi. org/ 10.

25080/ TCWV9 851

53. Barnes J, Hut P (1986) A hierarchical O(N log N) force-calculation algo-

rithm. Nature 324(6096):446–9. https://doi.org/10.1038/324446a0https://

doi. org/ 10. 1038/ 32444 6a0

54. Verdú J, Pajuelo A (2016) Performance scalability analysis of JavaScript

applications with web workers. IEEE Comput Archit Lett 15(2):105–8.

https:// doi. org/ 10. 1109/ LCA. 2015. 24945 85

55. Haynes LS, Lau RL, Siewiorek DP, Mizell DW (1982) A survey of highly

parallel computing. Computer 15(1):9–24. https:// doi. org/ 10. 1109/ MC.

1982. 16538 23

56. Goldman M, Craft B, Hastie M, Repečka K, McDade F, Kamath A et al

(2020) Visualizing and interpreting cancer genomics data via the

Xena platform. Nat Biotechnol 38(6):675–8. https:// doi. org/ 10. 1038/

s41587- 020- 0546-8

57. Samek W, Binder A, Montavon G, Lapuschkin S, Müller KR (2017) Evaluat-

ing the visualization of what a deep neural network has learned. IEEE

Trans Neural Netw Learn Syst 28(11):2660–73. https:// doi. org/ 10. 1109/

TNNLS. 2016. 25998 20

58. Schall G, Zollmann S, Reitmayr G (2013) Smart Vidente: advances in

mobile augmented reality for interactive visualization of underground

infrastructure. Personal and Ubiquitous Computing 17(7):1533–49.

https:// doi. org/ 10. 1007/ s00779- 012- 0599-x

59. Community V (2024) Vis.js. https:// visjs. org. Accessed 12 Apr 2024

60. Franz M, Lopes CT, Fong D, Kucera M, Cheung M, Siper MC et al (2023)

Cytoscape.js 2023 update: a graph theory library for visualization and

analysis. Bioinformatics 39(1):031. https:// doi. org/ 10. 1093/ bioin forma tics/

btad0 31

61. Angel E, Haines E (2017) An interactive introduction to WebGL and three.

js. In: Proceedings of the ACM SIGGRAPH 2017 courses, ACM, Los Angeles.

https:// doi. org/ 10. 1145/ 30848 73. 30848 75

62. Elzen SVD, Holten D, Blaas J, Van Wijk JJ (2014) Dynamic network visualiza-

tion with extended massive sequence views. IEEE Trans Vis Comput

Graph 20(8):1087–99. https:// doi. org/ 10. 1109/ TVCG. 2013. 263

Publisher’s Note

Springer Nature remains neutral with regard to jurisdictional claims in pub-

lished maps and institutional aﬃliations.

2 views·17 pages

Graph visualization efficiency of popular web-based libraries PDF Free Download

Graph visualization efficiency of popular web-based libraries PDF free Download. Think more deeply and widely.

Uploaded by Jodi Hernandez on 4/18/2026

/17

100%