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

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 pathway Insulin-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 graphics Still, 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 graphics Today 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 rendering With 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 recommendation So 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 with So 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 DEMO Give 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-6700 Simple SVG Complex SVG Simple Canvas Complex Canvas Simple WebGL Optimized, static WebGL N = 100, M = 150 60 60 60 60 60 60 N = 1k, M = 1k 60 NR 60 NR 60 60 N = 2k, M = 2k 50 NR 53 NR 60 60 N = 5k, M = 5k 23 NR 23 NR 46 60 N = 10k, M = 11k 10 NR 11 NR 20 60 iPad Air 2013 Simple SVG Complex SVG Simple Canvas Complex Canvas Simple WebGL Optimized, static WebGL N = 100, M = 150 55 NR 60 9 60 60 N = 1k, M = 1k 17 NR 24 NR 40 60 N = 2k, M = 2k 7 NR 8 NR 20 60 N = 5k, M = 5k NR NR NR NR 10 60 N = 10k, M = 11k NR NR NR NR NR 60 Galaxy Tab 2014 Simple SVG Complex SVG Simple Canvas Complex Canvas Simple WebGL Optimized, static WebGL N = 100, M = 150 22 NR 26 NR 35 35 N = 1k, M = 1k 7 NR 7 NR 10 35 N = 2k, M = 2k NR NR NR NR NR 35 N = 5k, M = 5k NR NR NR NR NR 30 N = 10k, M = 11k NR NR NR NR NR 20 MacBook 12" 2015 Simple SVG Complex SVG Simple Canvas Complex Canvas Simple WebGL Optimized, static WebGL N = 100, M = 150 60 18 60 19 60 60 N = 1k, M = 1k 40 NR 55 NR 60 60 N = 2k, M = 2k 20 NR 28 NR 44 60 N = 5k, M = 5k NR NR 11 NR 20 60 N = 10k, M = 11k NR NR NR NR 12 60 Surface i7-6650U Simple SVG Complex SVG Simple Canvas Complex Canvas Simple WebGL Optimized, static WebGL N = 100, M = 150 60 28 60 15 60 60 N = 1k, M = 1k 40 NR 55 NR 60 60 N = 2k, M = 2k 23 NR 28 NR 50 60 N = 5k, M = 5k 9 NR 12 NR 24 60 N = 10k, M = 11k NR NR NR NR 14 60

yWorks releases version 2.1 of yFiles for HTML!

The 2.1 release of our graph drawing and network visualization library yFiles for HTML contains a lot of new features that both our existing customers and new customers can benefit from. In this blog-post I would like to highlight some of the most important new features which you will find in this new release. If you are new to the product, though, a better introduction to the capabilities and features might be this page. As usual, the release contains improvements and new features across the whole product, be it for non-visual goodies for developers, in the area of automatic layout, or on the visual and interactive side of the API. Automatic Layout With the newest release, we added a few new simple layout styles and layout utilities, but we also implemented massive improvements for the orthogonal layout and automatic tree layouts: Orthogonal Layout Improvements The orthogonal layout algorithm is now able to detect special substructures, i.e., trees, chains and cycles, and apply specific layout styles to each of them - this significantly improves the recognition of such structures. In addition, we applied several improvements to the orthogonal layout that increase both the readability and compactness of the resulting drawings. The first example shows a simple tree where the improvements are really significant. The second example shows a larger graph which is now drawn much more compact and with a uniform port assignment. Another improvement of the orthogonal layout is the specific routing of parallel edges. Compared to the previous version in which parallel edges were routed independently, the new version routes them in parallel which makes it much easier to recognize such edges. New Tree Map Layout Hide DescriptionOpen in yEd LiveDownload We added a new layout algorithm that produces so-called "tree map" layouts. Tree maps use nested rectangles to visualize hierarchical data structures like, e.g., the file structure on a hard disk where the size of the rectangles correlates with the size of the associated file/folder: Compact Tree Layout We also added a new, compact layout style for trees that is especially suitable for organization chart diagrams. The compact layout style applies different placement strategies to sub-trees such that the resulting diagrams are much more compact compared to those created with the default directed layout style. It was possible to get similar results, previously, too. But this meant that for each subtree, the developer had to manually choose the right strategy for the arrangement. With the new implementation, this happens all automatically. Sub Components for the Hierarchic Layout For the hierarchic layout style we added a new feature that allows to specify different sub-graph components. Each such component is first arranged with a user-specified layout algorithm and then embedded into the global hierarchic layout. View and Interaction 2.1 of yFiles for HTML received one major upgrade on the viewer side, but there were also incremental changes in the area of touch-interaction: Touch Interaction Improvements A new way of selecting a set of elements on the screen has been introduced by means of the lasso free-hand selection tool. This is great, especially on touch input devices, but can also be used with the mouse. In this release there is also a completely new demo that shows possible customizations for interactions on touch-enabled devices. It features a context menu dial for touch, customized hit-test sensitivity unique handle styling, and more. WebGL as a Third Rendering Option The addition of WebGL to the rendering stack enables the visualization of even the most complex graphs and networks. For the 2.1 release we decided to not only support SVG and Canvas for the rendering of the diagrams, but we also added the option to render large networks with the power of hardware accelerated WebGL. WebGL can provide huge performance boost on slower mobile devices, which previously showed significantly slower performance for large networks. The unique visualization technology allows for seamlessly mixing all three technologies in the same visualization and at the same time. Developer Goodies We always do our best to please the developers that are creating all of these awesome applications with our tools. In the JavaScript/TypeScript world, this means we always have to keep up with the latest trends, tool-kits, and technologies. This release is all about ECMAScript 2015 modules, a.k.a. ES6 modules. With the recently added native browser support for this technology and the prevalence of this feature in modern cross-compiled JavaScript code-bases, we decided to support this technology as an option for developers natively, too. With the new ES6 modules for yFiles for HTML, programming in TypeScript and with Angular feels absolutely great. Starting with the 2.1 release there are two versions of the library bundled with the package: A native ES5 variant that runs in all browsers starting with Internet Explorer 9 without any pre-processing and a variant implemented as a set of native ES6 modules that may be imported directly from JavaScript using the import-statement in supporting browsers. The new ES6/ES2015 variant will mostly be used together with modern development tool-chains like webpack and TypeScript and massively improves the developer experience for devs working on modern Angular-cli projects Together with the complete typescript definition files for both versions of the library, it's now super easy to write clean code with great IDE tooling support for code completion, type-checking, and documentation lookup. And since Visual Studio Code has become a very popular lightweight IDE for many developers in the JavaScript and TypeScript community, we are now offering optimized code completion files with complete type definitions for both Visual Studio Code and the major JavaScript and TypeScript IDEs from our friends at JetBrains. If you're a developer, give it a try and see how this will improve your coding efficiency and code quality!

yFiles layouts in Cytoscape 3.6.0

On November 15th, the Cytoscape project announced the new version 3.6.0 of the Cytoscape software.This new version partners with the new yFiles Layout Algorithms for Cytoscape app to make available the latest yFiles layout algorithms in Cytoscape! Hide DescriptionOpen in yEd LiveDownload yFiles Layout Algorithms for Cytoscape app The yFiles layouts provided by the app bring you professional layout algorithms and let you benefit from better performance than ever before.Install the yFiles layouts in the Cytoscape GUI with the Install yFiles Layout... command from the Layout menu or download the app from the Cytoscape App Store! yFiles-powered The automatic layout algorithms of the yFiles family of diagramming libraries is what powers the "yFiles Layout Algorithms for Cytoscape" app. But the yFiles software components have even more to offer: The professional yFiles diagramming software components enable you to add high-quality diagramming functionality to your own software applications: turn your data into clear diagrams with the help of unequaled automatic diagram layout, use rich visualizations for your diagram elements, and give your users an intuitive interface for smooth interaction.yFiles is available for a wide range of platforms and technologies: from web applications to cross-platform Java(FX) to the Microsoft .NET environment.

New major release yFiles for JavaFX 3.1

This new version brings huge rendering performance improvements and many new performance-related configuration options. Also, an extensive graph editor application shows the integration with the Eclipse e4 API of the Eclipse Rich Client Platform. Hide DescriptionOpen in yEd LiveDownload Especially for large graphs the general rendering performance was improved substantially. New rendering policies were added that boost edge rendering performance with non-solid pens and with selection, highlight, and focus indication. The graph editor mini application is part of the demo applications and comes with full source code. It shows the integration with the Eclipse e4 API of the Eclipse RCP and features extensive functionality for the configuration of node and edge properties, for running automatic layouts, and for graph analysis tasks with the structure view and neighborhood view components. Find out more...