Posts labeled "yFiles AJAX"

yWorks releases version 2.2 of yFiles AJAX!

This version is based on Dojo 1.10.4 and uses yFiles for Java 2.12, which adds new automatic layout algorithms on the server: a new layout algorithm for radial layout that places nodes in a concentrical fashion, and the new series-parallel layout algorithm that is designed to handle two-terminal graphs.
The Balloon style tree layout algorithm brings new placement options and new integrated node labeling support. The tree layout algorithm provides new multi-parent support to handle local non-tree structures, and the hierarchical layout style brings new grid placement support for nodes and edges.
Also new is functionality to abort lengthy calculations of automatic layout algorithms.

Releases yFiles AJAX

yWorks releases version 2.1 of yFiles AJAX!

This version is based on Dojo 1.8.3 and uses yFiles for Java 2.10, which adds new automatic layout algorithms on the server: a new edge routing algorithm that can generate orthogonal as well as octilinear edge paths, and also new support for octilinear edge paths in the hierarchical layout algorithm.

Releases yFiles AJAX

yWorks releases version 2.0 of yFiles AJAX!

This version brings a new SVG mode for vector-based visualization of diagrams in the browser and new support for diagram navigation using touch gestures on iOS and Android devices.

Releases yFiles AJAX

yWorks releases version 1.4 of yFiles AJAX!

This version is based on Dojo 1.5 and uses yFiles for Java 2.8.
It brings new client-side functionality for resizing graph elements and Undo/Redo support. Also, new callbacks support convenient server request monitoring.

Releases yFiles AJAX

yWorks releases version 1.3 of yFiles AJAX!

This version is based on Dojo 1.4.0 and uses yFiles for Java 2.7.
It brings new client-side functionality for highlighting graph elements, improves presentation when updating image tiles, and introduces many new configuration options.

Releases yFiles AJAX

Back

Popular Blog Posts

‘Game of Thrones’ Relationship Graph

Every year, the Graph Drawing conference organizes a contest which sets the task to visualize predetermined graph data. This year, the data consists of a graph that presents the relationships between 84 characters from the popular TV series ‘Game of Thrones’. Since our yFiles diagramming library is designed to arrange and visualize graph structures, we decided to participate in the contest. The image above shows a preview of our contribution. Read on if you want to find out how we created it or skip to the final result.Getting to know the dataFirst, we used yFiles to quickly parse the provided GraphML file into a graph in which each node represents a character and each edge between two characters indicates a specific relationship.Hide DescriptionOpen in yEd LiveDownloadApplying different yFiles layout algorithms to the graph provided insight into the overall structure of the connections. However, the data contains more information which is not depicted in these standard views:The full name of each character, its affiliation to a house, family, or group, and whether they are alive or deceased.The type of relationship; this can be a killing, an allegiance, or a family tie. In the latter case, the type further differentiates between spouses, parents, siblings, and lovers.In addition some parts of the graph are tightly connected which surely makes it difficult to follow the paths of the connections.Introducing structureSo how do we restructure the data such that a more structured arrangement can be achieved?Since the story of the TV series is all about different families and groups which are competing for power, we decided to divide the characters by their affiliation to the different houses/families.We introduced new nodes that represent the houses and connected every member of a house to the respective house node. Allegiances and family relationships between members of two different houses are redirected to the house nodes to keep them from spanning across the whole graph. Furthermore, we sized the nodes according to the number of allegiance edges to which they were incident initially. This makes more important characters easily recognizable.Graph layoutThe next step was to actually find a good way to arrange the data. We implemented a custom layout algorithm on top ofthe available algorithms from the yFiles diagramming library.To emphasize the affiliation of the characters to the houses, we made the algorithm place the house nodes in a circle and arrange the members of a house in the according sector.The families get placed on concentric circles around the center of the inner circle. Children are placed further outside than their parents while we tried to set spouses and lovers on the same circle. Characters that are associated to just one house, like servants, dragons or direwolves, are also assigned to the respective house.There are two characters (High Sparrow, Night King) located outside the sectors because they do not belong to any house and are only connected through a kill.There are three types of edges: family ties, allegiances, and killings. We used different edge routing algorithms for those edges so they became easily distinguishable. Edges that describe family relations or allegiances are straight lines when they appear inside a house sector. Inside the inner circle they get routed in arcs whose thicknesses represent the number of edges between two houses.Finally, the kill edges were quite a challenge. They connect characters from all parts of the diagram and there are many of them. After some experiments, we decided that they must run outside the inner circle. They were implemented as two straight segments and an arc. This way they can easily be distinguished from the other types of connections. Of course, we tried to minimize the number of crossings to make it easier to follow the edges.Styling the diagramCreating a clear arrangement of the characters and routing the connections between them was the first important step. But a diagram where nodes are only simple, colored shapes and edges are black lines with an arc is not really an eye-catcher. Using yFiles with its many styling options we were sure it would be easy and fun to change that situation. The nodes on the inner circle carry the emblem of the house or group they represent. They mark the sector as well as the end points for the inner edges.Characters are visualized using a picture of a person or animal along with their name. The border shows the color ofthe house to which the character belongs by birth.Since there are three different kinds of edges, we decided to give them different colors. Edges that represent family relationships are drawn in the color of the family’s house. In case those edges connect to two house nodes, theychange color in the middle. Allegiance edges are drawn using dark blue, dotted lines, independent of where the edge is located.As previously mentioned, kill edges are routed in different style. To separate them even more from the other edges, they have a dark red color. Their direction, i.e. who killed who, is indicated by port icons. The source is marked with a bloody knife while at the target a skull is shown.The final resultBelow you find the final diagram created by our algorithm which combines all described features.So now that we have a concise layout of the data and also a nice visualization of the diagram elements, what can we learn from the visualization? We think that the diagram provides a lot of information at a glance. Important characters can easily be recognized by their size and by the amount of relations they have. The large, most important houses immediately stand out.Even though someone who is very familiar with ‘Game of Thrones’ will probably not learn something totally new, our diagram makes it very easy and efficient to get an overview over the involved groups and characters.How do you like the results? Let us know! Just leave us a message in the social media or using our contact information.

Automatic Metro Map Generation

Metro maps are a very important tool when it comes to illustrating routes of a public transport system. The history of metro maps or, more generally, transport maps, goes back to the famous 'Tube Map' created by Harry Beck in 1931 which shows the London Underground. Nowadays they exist for almost every larger urban area, making it easy for passengers to quickly gain an overview over the possible routes and reachable stations. Simply put, metro maps consist of stations or stops which are connected by lines. So we thought that they are a perfect match for the visualization using our yFiles diagramming library. Our goal was to automatically generate maps from data retrieved online and to polish the results using styles similar to the ones found in official maps. As the computation of a new metro map layout is quite CPU intensive, the goal was not to create maps in real time.The automatic computation of metro maps is very CPU intensive.Getting dataFirst, we needed to get the transport line data. We solved this by using OpenStreetMap and overpass-turbo which uses the Overpass-API to query data from OpenStreetMap. It allowed us to quickly and automatically query data for public transport systems of any desired area, parse it, and create a yFiles diagram from it. What we got is basically a diagram that shows the transport system in a geographically precise way:Hide DescriptionOpen in yEd LiveDownloadModeling and solving the problemOur maps should satisfy a few general visualization rules, shared by most of the official maps, too. The lines should only be either horizontal, vertical, or diagonal at 45 degrees. Such a line layout is referred to as octilinear. Metro maps must preserve the main geographic character, like the relative location of stations, but they do not need not to be geographically precise. Generating metro maps following these rules is a rather well-researched topic. Our solution follows the approach from Martin Nöllenburg ('Automated Drawings of Metro Maps', 2005). Shortly put, the approach models the problem using a mixed-integer linear program (MIP). The solution of the problem yields the coordinates of the stations.Metro maps preserve the main geographic character, but do not need to be geographically precise.In our implementation we mainly created constraints as proposed by Nöllenburg and applied an MIP solver (via API) to get a solution to the problem.We tried both lpsolve and the CPLEX Optimizer. The latter provided us with good results a lot quicker than the former. The solution of the MIP program is then interpreted and transferred to the yFiles diagram created in the first step, yielding a metro map layout. To improve the runtime and results we applied some additional heuristics, too.Visualizing the resultsNow we already had a metro map drawing, but we also wanted to make it look great. Here, our powerful yFiles visualization API came into play and made it fun to style the metro map diagram. For the lines we use the colors from the OpenStreetMap data, if available. Station nodes are automatically drawn smaller or larger, depending on the number of adjacent metro lines.The last challenge was the labeling of the metro stations (modeled as node labels). This is quite a difficult problem by itself, because in larger maps, there is often little space available for sometimes long label texts. With the help of the generic labeling algorithm (available out-of-the-box from the layout library) this challenge became manageable. To make results more similar to real-world maps, we tried to place labels as uniformly as possible and automatically used word-wrapping if there is little space available for a label.Labeling of the metro stations was a challenge, but easy with yFiles. Looking at our final results, we think that the maps can already keep up with some of the official metro maps! And clearly, the results of our automatic approach could be the base for a designer to further fine-tune the maps in some aspects. But have a look yourself: below you will find some of our results. Click the images to see the complete gallery of scrollable and zoomable high-quality vector graphics metro maps for more than a dozen cities!What do you think? Is this something we should include as an algorithm in yFiles? Let us know! Just leave us a message in the social media or using our contact form. The complete algorithm we implemented here is not currently part of the yFiles library. The labeling and visualization part is included in yFiles, but the linear programming part currently depends on third party software. If you are interested in using the algorithm for your own diagrams, please contact our support team for options.

Visualizing Neo4j Database Contents Like a Pro!

There are two major use-cases for the visualization of data in graph databases like Neo4j: Visualization can help database administrators and developers understand their Neo4j database schema as well as browse the contents and verify their queries using tools like Cypher and the Neo4j Desktop. But not only developers and backend devs can benefit from visualization: Many end-user applications that let the users work with data that is stored in graph databases also benefit a lot from a more visual interface to their data: Hide DescriptionOpen in yEd LiveDownloadEnd-user applications that let the users work with data benefit a lot from visual interfacesCreating a user-friendly, well-performing, and informative visualization for end-users is all but trivial and the simple visualizations that developers use for their tools often simply don't cut it. In this post I am going to present a tool that can help you with that task. With it, you can create high-quality graph and diagram visualizations for end-user applications, that perfectly convey the information contained in your database to the end user. With only slightly more than 60 lines of code we will create an interactive web application that renders a unique diagram of your data. This is what it will look like when used with the movie sample database: Professional Diagramming: yFiles for HTML The tool I am using for this is yFiles for HTML - a generic graph visualization programming library for the web platform that can help you realize those last ten or twenty percent of your requirements that you won't be able to implement with other tools: yFiles is a whole family of graph visualization programming libraries that have been available commercially for various target platforms for more than 15 years now and which are used by companies and corporations around the world coming from a wide range of diverse industries. The variant for the web platform is not exclusively meant to be used as a visualization front-end for Neo4j, however in this post I will show you how well yFiles for HTML and Neo4j play together. yFiles for HTML can help you realize those last 20% of your requirements that you won't be able to implement with other tools The single-page web app that we are about to build uses yFiles for HTML and the Neo4j JavaScript Bolt driver to query your very own Neo4j database. The query results will be displayed in a graph visualization with a unique automatic layout, customized item visualizations and user interactions. To follow the instructions in this post, you can download a free evaluation version of the yFiles for HTML software package and you should have a Neo4j database running that you can use for testing. In this post we are only going to briefly touch the surface of the yFiles API and vast array of possibilities and features that yFiles offers, so if you are interested in learning more, be sure to look at the various demos and online resources, too, or see this YouTube Playlist on that topic. Also, as an existing Neo4j user, be sure to check out the free online Neo4j Explorer web application that will help you visualize your database without all the coding! Let's start coding! We begin by scaffolding a bare minimum WebPack powered ES6-sources-based yFiles for HTML application that does not depend on any third-party software at runtime. We could also be using UI frameworks like Angular, React, VueJS, or anything similar, but for the sake of simplicity we are going to use plain vanilla HTML, here. After unzipping the yFiles for HTML library to some directory in our computer we can use npm or yarn and yeoman to scaffold the application. More detailed instructions are available in a separate screencast. On the console we do: > npm install -g generator-yfiles-app > yo yfiles-app And yeoman will ask you some questions. Here are the answers I chose for this task: ? Application name Neo_post ? Path of yFiles for HTML package C:\Path\to\your\yFilesForHTMLPackage ? Path of license file (e.g. 'path/to/license.js') C:\Path\to\your\yFilesForHTMLPackage\demos\resources\license.js ? Which kind of yFiles modules do you want to use? ES6 Modules ? Which modules do you want to use? yfiles/algorithms, yfiles/layout-hierarchic, yfiles/view-component, yfiles/view-editor, yfiles/view-layout-bridge ? Which language variant do you want to use? ES6 ? Which webpack version would you like to use? 4.x ? What else do you want? WebStorm/PHP-Storm/Intellij IDEA Ultimate Project files ? Which package manager would you like to use? yarn Then yeoman will do its magic and after a few seconds it will have scaffolded a shiny new web application that uses yFiles for HTML and Webpack 4 with ES6/EcmaScript2015 to load, layout, and render a trivial graph that you can edit interactively with the mouse, keyboard, and on touch devices. And this is what the app will look like when we use `npm start` or `yarn start` to compile, serve, and run the code in our browser:You will agree with me that this is not really an outstanding visualization, yet, and what we really want to do is inspect our Neo4j database contents! Introducing Cypher and Bolt To connect Neo4j with yFiles for HTML, we first add the JavaScript Bolt driver to our application. On the console we do: > yarn add neo4j-driver Then in the code we simply load the Neo4j driver by adding the following import statement at the top of the file:import neo4j from 'neo4j-driver/lib/browser/neo4j-web' Make sure you have the credentials and IP address available for the Neo4j database that you would like to explore, because with the next line of code, we can already connect to the database:const neo4jDriver = neo4j.driver("bolt://1.2.3.4", neo4j.auth.basic("theusername", "theS3cr3t")) (Of course, you will need to adjust the IP address, the user name and the password.) We are now going to simplify the scaffolded code first that yeoman created for us. Strip it down so that it looks like this: const neo4jDriver = neo4j.driver("bolt://1.2.3.4", neo4j.auth.basic("theusername", "theS3cr3t")) const graphComponent = new GraphComponent('#graphComponent'); loadGraph(); async function loadGraph() { let nodeResult = await runCypherQuery("MATCH (node) RETURN node LIMIT 25"); } async function runCypherQuery(query, params) { const session = neo4jDriver.session('READ'); try { return await session.run(query, params); } finally { session.close(); } } This will result in a boring empty graph view, because we only queried the database for the nodes, but we are not doing anything with the results, yet. At this point it is important to understand that the core yFiles for HTML library does not know how to interpret the results of a query returned by the Neo4j Bolt connector. However, there are utility convenience classes that will help us with the import of any kind of structured data that we have access to in our JavaScript environment. The data could be fetched from a file, from the network, via REST, WebSockets, or created dynamically on the client and of course, the Neo4j data works with this, too: All we need to have is some understanding of the way the Neo4j response data is structured. For the simple query above the resulting JavaScript object looks like this: { "records": [{ "keys": ["node"], "length": 1, "_fields": [{ "identity": { "low": 0, "high": 0 }, "labels": ["Movie"], "properties": { "title": "The Matrix", "tagline": "Welcome to the Real World", "released": { "low": 1999, "high": 0 } } } ], "_fieldLookup": { "node": 0 } } We can use the following Bolt JavaScript API to obtain an array of all the nodes queried: const nodes = nodeResult.records.map(record => record.get("node")) Now that we have the nodes, we can use the convenience class GraphBuilder from yFiles to get the graph onto the screen: graphBuilder.nodesSource = nodes graphBuilder.buildGraph() That was easy! But the result still leaves a lot to be desired from a visual and interactive perspective: Let's improve that: we assign a nicer style for the node visualization and a simple label mapping: If the node has a property named "title" or "name" we use this for the label. And instead of leaving all nodes at the default location, we apply an automatic layout algorithm to arrange the nodes nicely on the screen. import {GraphBuilder, GraphComponent, ShapeNodeStyle} from 'yfiles/view-component' import 'yfiles/view-layout-bridge' import {RadialLayout} from 'yfiles/layout-radial' graphBuilder.graph.nodeDefaults.style = new ShapeNodeStyle({shape:"ellipse", fill:"lightblue"}) graphBuilder.nodeLabelBinding = node => node.properties && (node.properties["title"] || node.properties["name"]) graphBuilder.buildGraph() await graphComponent.morphLayout(new RadialLayout()) The graph looks nicer, now, but we still don't see any relations. Let's change that with another query to the database! We query all the edges between the nodes that we have queried before using this code:const nodeIds = nodes.map(node => node.identity) const edgeResult = await runCypherQuery( `MATCH (n)-[edge]-(m) WHERE id(n) IN $nodeIds AND id(m) IN $nodeIds RETURN DISTINCT edge LIMIT 100`, {nodeIds}) This is what a result looks like in JSON form:{ "identity": { "low": 7, "high": 0 }, "start": { "low": 8, "high": 0 }, "end": { "low": 0, "high": 0 }, "type": "ACTED_IN", "properties": { "roles": ["Emil"] } } As you can see, the relationships reference their source and target nodes via the identity property that was attached to the nodes. We can use the toString function provided by Bolt, to obtain a representation of the identities that can be consumed easily by GraphBuilder. We tell the helper class to use this information to resolve the connections end points and build the in-memory graph for the display: const edges = edgeResult.records.map(record => record.get("edge")) graphBuilder.edgesSource = edges graphBuilder.sourceNodeBinding = edge => edge.start.toString() graphBuilder.targetNodeBinding = edge => edge.end.toString() graphBuilder.nodeIdBinding = node => node.identity.toString() Putting it all together this is what we have now in our loading function:async function loadGraph() { let nodeResult = await runCypherQuery("MATCH (node) RETURN node LIMIT 25") const nodes = nodeResult.records.map(record => record.get("node")) const nodeIds = nodes.map(node => node.identity) const edgeResult = await runCypherQuery( `MATCH (n)-[edge]-(m) WHERE id(n) IN $nodeIds AND id(m) IN $nodeIds RETURN DISTINCT edge LIMIT 100`, {nodeIds}); const edges = edgeResult.records.map(record => record.get("edge")) const graphBuilder = new GraphBuilder(graphComponent.graph); graphBuilder.graph.nodeDefaults.style = new ShapeNodeStyle({shape:"ellipse", fill:"lightblue"}) graphBuilder.nodesSource = nodes graphBuilder.nodeIdBinding = node => node.identity.toString() graphBuilder.nodeLabelBinding = node => node.properties && (node.properties["title"] || node.properties["name"]) graphBuilder.edgesSource = edges graphBuilder.sourceNodeBinding = edge => edge.start.toString() graphBuilder.targetNodeBinding = edge => edge.end.toString() graphBuilder.edgeLabelBinding = edge => edge.type graphBuilder.buildGraph() await graphComponent.morphLayout(new RadialLayout()) } And this is what the visualization looks like in the browser:We still need to work a little on the interactivity, the layout, and the visualization. Right now, we are hardly any better than most other tools. Let's say we want to show some details in a tool-tip, let the user select elements and react to clicks in the graph. For this we add the so-called GraphViewerInputMode to our component: const inputMode = new GraphViewerInputMode() graphComponent.inputMode = inputMode This enables the user to select elements, pan around conveniently, and use the keyboard to navigate the graph.We can now also easily specify rich tool-tips for our elements: For this we use the information that the database provided us with and we list all the properties in a very simple HTML list:inputMode.addQueryItemToolTipListener((sender, args) => { if (args.item && args.item.tag && args.item.tag.properties){ args.toolTip = `<ul> ${Object.entries(args.item.tag.properties).map( e => '<li>' + e[0] + ' : ' + e[1] + '</li>').join('')} </ul>` } }) And in order to better understand the structure of the graph, we add the option for the user to center the layout around a given item that she double-clicks:inputMode.addItemDoubleClickedListener(async (sender, args) => { if (INode.isInstance(args.item)){ args.handled = true; const radialLayoutData = new RadialLayoutData() radialLayoutData.centerNodes.items.add(args.item) const radialLayout = new RadialLayout() radialLayout.centerNodesPolicy = "custom" await graphComponent.morphLayout(radialLayout, "0.5s", radialLayoutData) } }) That's it. Check out the final code, again:I guess you can see that with only very little customizations you are now able to adjust the Cypher queries to your specific databases and create rich, interactive, visualizations of your data! That's it already for this very short introduction on how to use yFiles for HTML to visualize your Neo4j databases. You will find a commented version of the sources for this demo on GitHub. What next? Of course, there is a lot more functionality that has not yet been covered in this post. Take a look at the many online demos for yFiles for HTML to get an idea what else you could do with the yFiles libraries and Neo4j! I leave it as an exercise for you to improve the visualization to look like this :wink:: And to give you more ideas about the possibilities, with some coding, yFiles for HTML, and Neo4j you can: use WebGL, Canvas, and SVG together with templating and databinding to create richer visualizations with animations and just the right information your users require connect to third-party data-sources and services to enhance your visualization with live data and let the user trigger actions in remote systems when interacting with the visualization embed the graph visualization as a white-label component into your very own apps, possibly using Angular, ReactJS, VueJS, or whatever framework you prefer interactively explore the database and incrementally add new elements to the visualization using incremental automatic layouts use different, more compelling layout styles and provide more sophisticated layout constraints to highlight certain structures, components, or elements in your dataset in the visualization use nesting, filtering, and drill-down techniques to let your users interactively explore your data enable users to edit your graphs using the mouse, keyboard, pen, and touch devices So, what are you waiting for? Go and visualize your Neo4j database like a pro! Happy diagramming! This post was originally posted on Medium in cooperation with our friends at Neo4j.There is a screen-cast available on YouTube that goes through the steps in this post.

Visualization of SBGN Process Description Maps

Recently we have started working on the visualization of SBGN process description maps. SBGN stands for Systems Biology Graphical Notation and is an effort to provide a standardized graphical notation for molecular and system-biology applications that describe biological pathways/networks. Pathways are modeled as abstract graphs and, thus, we can apply our yFiles diagramming library for their visualization. Visualization facilitates the communication of complex information and, thus, is especially useful for such applications with their huge amount of structured data. SBGN defines three different visual languages and the Process Description (PD) language is one of them. It is used for the visualization of the temporal courses of biochemical interactions and originates from a graphical notation system proposed by Kitano in 2005. It is, for example used in the CellDesigner tool, a modeling tool for biochemical networks. There are several large databases for pathways that use such a visual representation like the Reactome and Panther database. While some of the databases already contain pathways with layout information (i.e. coordinates of the elements), the majority of them doesn’t. Furthermore, most of the diagrams with layout information were drawn manually. While such manually drawn diagrams are often of good quality, the creation of such diagrams is very time consuming. The demand of sophisticated automatic layout algorithms, the huge amount of available data as well as the increasing importance of system-biology in the last decades makes this field an interesting topic for us.Drawing Pathways in yEd We have integrated a new palette section into our free graph editor yEd that provides specific elements/glyphs required to draw SBGN process description maps. After manually creating a pathway, users can utilize the various cutting-edge layout algorithms provided by yEd to automatically create appealing layout results. The most suitable algorithms for pathways are the force-directed approach (called “Organic” in yEd), the hierarchical layout approach (called “Hierarchical” in yEd) as well as the orthogonal layout approach (called “Classic Orthogonal” in yEd). The force-directed approach distributes nodes in a natural way and uses straight-line edge routes. The hierarchical layout approach (also known as layered or Sugiyama-style layout approach) places the nodes in different layers such that the edges point in a common, user-specified layout direction and, thus, emphasize the natural flow of information. Compared to force-directed approaches, the hierarchical layout approach uses polyline/orthogonal edge routes and never produces overlaps between elements. The orthogonal layout algorithm is based on the "topology-shape-metrics" approach and usually produces drawings with few bends and crossings using orthogonal edge routes. It is especially suitable for smaller pathways with low density (i.e., edge/node ratio). Besides providing sophisticated layout algorithms, yEd also assists users in making further manual adjustments to their diagrams. For this it offers several tools like snap lines, grid snapping and routing of a subset of edges.Hide DescriptionOpen in yEd LiveDownload Creating a pathway with yEd. The middle part shows the editor window and the upper right part the SBGN palette containing all the glyphs required to draw process description maps.Applying a Custom Layout Algorithm to Pathways While the mentioned state-of-the-art layout algorithms of yEd already produce suitable results, we have also implemented a customized algorithm that is based on the orthogonal layout algorithm and, in addition, uses a packing algorithm for groups that only contain separated (disconnected) nodes. This is required to produce more suitable results for SBGN complex nodes that represent biochemical entities which are recursively composed of other entities and do not contain any edges. With our yFiles library, the library on which yEd is based on, we were able to realize the required modifications within a short time period. Below there are some examples that were automatically laid-out by our modified layout algorithm and show that it is able to produce very nice results for such smaller diagrams. There are also some more specific requirements that are currently not supported by this algorithm, like, e.g., process nodes where the production and consumption arcs should connect to opposite sides as well as the accentuation of important cycles of pathways. Both topics could be approached in future enhancements.Polyglutamine (polyQ) proteins interference pathwayInsulin-like growth factor signaling pathway

SVG, Canvas, WebGL? Visualization options for the web

Ever since we released our commercial graph drawing library for HTML5 and JavaScript/Typescript, we have been working hard to get the best possible performance that is available on the HTML5 platform: Our initial implementation six years ago only supported SVG, because we found it to be the most flexible, most widely available and easy to work with API for us and our customers, who are also developers. At that time (when Internet Explorer 9 was still in wide use), it already was the best performing technology, at least if you wanted to render high-quality, non-trivial, large-scale graphics.Over the years the situation with SVG actually improved: since most of the rendering logic takes place in native code and may even benefit from hardware acceleration, performance went up and cross-browser support improved even for the more advanced features like hardware accelerated filters and CSS3 transitions and animations for SVG elements.SVG was and is the best option for rendering high-quality vector graphicsStill, with the second major release of our library about four years ago, we decided to also add HTML5 Canvas as a possible rendering technique to our programming library. This meant that developers could use SVG or Canvas for rendering their visualizations and even mix both techniques in the same visualization. Why did we do that? For the technical kind of drawing, SVG is actually far superior over Canvas: it's easier to import graphical assets and performs better for non-trivial graphics. The reason was that for the very simple kind of graphics, where only simple lines and a few rectangles or maybe simple circles are required, the performance of Canvas is actually better if you have lots and lots of elements on the screen at the same time. Our component uses "virtualization" and does not render those elements which are currently scrolled off-screen, but if users want to display thousands of elements on the screen at the same time, SVG still could not compete with the performance of Canvas if the number of drawing primitives is high and the rendering is very simple. The DOM that is required for the rendering gets too big if thousands of elements are rendered using SVG on slower devices. That's where Canvas actually really shines and that's why we added Canvas rendering as an option.Canvas is faster for simple graphicsToday most of the time we recommend a hybrid-approach, which we call level-of-detail rendering: Once the user zooms into the visualization and only few elements are visible on the screen, we use SVG to display crisp, high-quality, complex vector graphics. But if the user zooms out to get an overview of the network or diagram, we seamlessly switch to Canvas rendering and use simpler visualizations of the elements that require fewer JavaScript calls to the Canvas API. For export, even for the zoomed out variant, we recommend sticking with SVG to get crisp, high-quality SVGs and PDFs that look great on large-scale print-outs and high-dpi screens. In this scenario it doesn't matter whether the export takes more than a few milliseconds, because you will only export the image once, whereas in an interactive scenario you might have to re-render the whole image 60 times per second to get the best possible experience for the end-user.Introducing WebGL renderingWith the 2.1 version of yFiles for HTML, among other things, we added yet another option to our rendering stack: WebGL is now also available to developers to choose from and just like with Canvas it is possible to mix all three technologies in the same diagram at the same time to get the best of all three worlds: WebGL rendering absolutely outperforms both Canvas and SVG when it comes to even simpler renderings that mostly consist of simple polygons. It doesn't work nearly as well with high-quality text-rendering and rendering complex graphics most of the time is even slower. But it does work fabulously well for the very high-level views of very large network visualizations! Even with the simple built-in on-chip graphics card adapters of today's desktop CPUs it is possible to render tens of thousands of elements on the screen at the same time with perfect frame rates. With medium class graphic card adapters on desktops more than one hundred thousand elements on the screen with great frame-rates is absolutely feasible. All ever-green browsers (Chrome, Firefox, Edge, Safari, and derivatives) support this technology and with WebGL, even mobile devices that are a lot slower than desktops CPU-wise can render a huge number of items with great frame rates using their built-in GPUs. Our recommendationSo what is our recommendation today? If you really need to display tens of thousands of elements on the screen at the same time, WebGL can be a real life-saver: Even for the typical hair-ball visualization you can achieve buttery-smooth 60 fps and once you zoom in more closely, you can add Canvas rendering to render the labels and for close-ups you can switch again to SVG to get high-quality, interactive, renderings and crisp graphics at great performance even on very high-DPI devices with hardware accelerated CSS effects and filters!And why did it take us so long to add WebGL to our rendering stack? WebGL at its core is a beast to work with. Without third-party libraries (which developers can use, if they want to program WebGL with our library), programming low-level WebGL that performs great is very hard. From a developer usability point of view, WebGL is certainly the least desirable of the three technologies, at least in the context of those types of visualizations that we deal with.WebGL is a beast to work withSo in a way we wanted to keep that complexity away from our customers, the developers. With the new release we added a number of default visualizations that they can use just like they were using the default SVG and Canvas visualizations. In this case, the complexity of WebGL is hidden behind an abstraction layer, so they don't need to deal with the complexity if they don't want to, but still get the good performance. As usual we still make it possible for developers to get their hands dirty: If they want to, they get the possibility to access the low-level APIs directly and program against SVG, Canvas, and WebGL without any layers in between or even with the third party library of their choice to help them with their tasks.Still, the main reason for us to wait with the release was a completely different one: We actually did not believe that it should be necessary to use WebGL: Even now that we have it in the stack, we still recommend not even trying to display networks and diagrams of that size, because of the (usually) rather poor user experience this results in: Many of these huge diagrams that you may have seen before do look great at first sight, however this is mostly from an artistic point of view. There is often very little real value in these diagrams: Sometimes simply printing the number of elements as a string would provide more information than the picture. It just wouldn't have that cool, super-complex look...Hide DescriptionOpen in yEd LiveDownload Sometimes simply printing the number of elements would provide more useful information than the picture. It just wouldn't look that cool.Usually we recommend applying filtering techniques in order to reduce the number of elements in the diagram to become a low three figure number at most. Ideally only a few dozen elements should be on the screen, because this is what the average human brain can best work with. This can be achieved using drill-down techniques, expand/collapse operations, master-detail views and simple filtering. The difficulty here lies in finding the right rules for the data-set. Only with a good domain-knowledge of the graph structure it is possible to come up with meaningful filter sets and groupings. Using generic structural-only graph analysis, often does not suffice, here, but domain-knowledge and graph analysis algorithms need to be combined.But once we get to these low numbers of items on the screen, SVG really is the best choice, today, and it will probably stay the best choice for a long time to come. Still, if developers want to present a nice and well-performing rendering of a "hair-ball graph" to their customers, with the inclusion of WebGL in yFiles for HTML, this is now possible.We have implemented a demo that shows the various pros and cons of the different rendering techniques. Everyone can try the demo online and switch between the various implementations to compare the performance of the three rendering techniques for diagrams at different sizes.RUN DEMOGive it a try and if you're a developer, we invite you to evaluate the software and start hacking away, today.And the winner is...So who is the winner? SVG, Canvas, or WebGL? For graph visualization clearly the combination of the three technologies is the winner! In the tables below you can see how the various technologies compare for different classes of devices. Values are in frames per second and 'NR' stands for 'not recommended'. We compared a moderately new desktop PC (2016) which performs well for reasonable graph sizes and any rendering technology against a set of quite old tablet devices. Even with the fairly outdated devices WebGL allows for smooth visualizations of even larger networks and you get fine performance for regularly sized diagrams. Our tests of more recent (2016/2017) small notebook devices shows that you can get smooth high-quality SVG visualizations with reasonable graph sizes and perfect performance for large networks using WebGL technology. PC Core i7-6700Simple SVGComplex SVGSimple CanvasComplex CanvasSimple WebGLOptimized, static WebGLN = 100, M = 150606060606060N = 1k, M = 1k60NR60NR6060N = 2k, M = 2k50NR53NR6060N = 5k, M = 5k23NR23NR4660N = 10k, M = 11k10NR11NR2060 iPad Air 2013Simple SVGComplex SVGSimple CanvasComplex CanvasSimple WebGLOptimized, static WebGLN = 100, M = 15055NR6096060N = 1k, M = 1k17NR24NR4060N = 2k, M = 2k7NR8NR2060N = 5k, M = 5kNRNRNRNR1060N = 10k, M = 11kNRNRNRNRNR60 Galaxy Tab 2014Simple SVGComplex SVGSimple CanvasComplex CanvasSimple WebGLOptimized, static WebGLN = 100, M = 15022NR26NR3535N = 1k, M = 1k7NR7NR1035N = 2k, M = 2kNRNRNRNRNR35N = 5k, M = 5kNRNRNRNRNR30N = 10k, M = 11kNRNRNRNRNR20 MacBook 12" 2015Simple SVGComplex SVGSimple CanvasComplex CanvasSimple WebGLOptimized, static WebGLN = 100, M = 150601860196060N = 1k, M = 1k40NR55NR6060N = 2k, M = 2k20NR28NR4460N = 5k, M = 5kNRNR11NR2060N = 10k, M = 11kNRNRNRNR1260 Surface i7-6650USimple SVGComplex SVGSimple CanvasComplex CanvasSimple WebGLOptimized, static WebGLN = 100, M = 150602860156060N = 1k, M = 1k40NR55NR6060N = 2k, M = 2k23NR28NR5060N = 5k, M = 5k9NR12NR2460N = 10k, M = 11kNRNRNRNR1460