Each node consists of an SVG ellipse with fill and stroke.
Each node consists of several SVG elements.
Each node is drawn as a filled and stroked ellipse.
Each node is drawn by lots of different draw statements into the canvas. Its visual complexity is similar to the complex SVG style.
Each node is drawn as a solid star using WebGL.
Uses the default rendering method that delegates the rendering to the item styles.
Uses the built-in WebGL2-based rendering method. This features high rendering performance for large graphs for both static and dynamic data and optimized code paths for user interaction.
On the downside, only the predefined styles can be used, some advanced features of the user interaction are not supported (e.g. snapping), and text rendering at high zoom levels is less clear. Note that WebGL2 is not supported in Internet Explorer and at the time of writing still needs to be enabled manually in the settings for Safari and on iOS.
This option is suited for almost all scenarios with a large graph and a moderate complexity of the items visualizations and label texts. If vector graphic quality is required at high zoom levels, it can be combined with level-of-detail rendering.
Uses a level-of-detail approach to render graph items. At intermediate and overview level, items are rendered with alternative styles and without labels. This can be used to assign simpler item styles that improve the performance in intermediate and overview level.
In this case, the simple SVG style is used for intermediate level, and the WebGL style for the overview level.
With this approach, the rendering still makes use of virtualization, i.e., visualizations are removed if the item leaves the viewport and re-created if it enters the viewport again.
This approach can be applied for dynamic editor scenarios where the graph structure or the item visualizations have to be changed often.
The graph visualization is created using the default rendering code. However, subsequent updates are ignored. This does not apply to canvas styles which do not have an update mechanism but are drawn anew each time.
This makes panning and zooming very efficient. However, structural changes to the graph, e.g., moving nodes or changing item styles do not result in an updated visualization. Use the auto redraw option in move and edit mode.
This option is best suited for viewer only applications with not too big graphs that rely on the actual item style.
This option creates a static SVG image of the complete graph at zoom level 1 and uses this image instead of calling the render code of the actual item styles.
In contrast to Static with Default Styles, this approach does not use virtualization, i.e., the complete graph is part of the DOM at all times.
It is best suited for static scenarios, e.g., viewer only applications with not too big graphs.
This option creates an image of the currently visible part of the graph, using HTML5 canvas.
The size of the pre-rendered image can be specified relative to the viewport size using FastGraphModelManager.ImageSizeFactor.
The image is updated for quality if the bounds of the image are reached through panning, or if
the zoom level changes by a factor greater than FastGraphModelManager.RefreshImageZoomFactor.
The items in the graph are drawn using FastGraphModelManager.DrawNodeCallback, FastGraphModelManager.DrawEdgeCallback etc.
This option is suited for scenarios with a large graph where the zoom level changes frequently. Since the items are drawn with a (simple) canvas paint callback, the visualization can be created very quickly, while still remaining a high-quality image. However, the item visualizations are simplified compared to the actual item styles. A short freeze can occur when the image is re-created.
This option creates an image of the currently visible part of the graph,
using HTML5 canvas.
The items are drawn using the item styles.
The size of the pre-rendered image can be specified relative to the viewport size using FastGraphModelManager.ImageSizeFactor. The image is updated for quality if the bounds of the image are reached through panning, or if the zoom level changes by a factor greater than FastGraphModelManager.RefreshImageZoomFactor.
This option is suited for scenarios with a large graph where the zoom level changes frequently. In contrast to Simple Dynamic Canvas Image, the actual item styles are used to draw the graph. Based on the style, this can be quite expensive and thus can result in worse image creation performance. Thus, the "hiccups" during zooming and panning can be longer.
This option exports a HTML5 canvas image of the complete graph and draws it into the GraphComponent. The item styles are used to draw the image.
Since the image is not dynamically re-created if the zoom level changes, this option produces bad results for higher zoom levels. It is only suitable for scenarios where the graph is drawn with very low zoom levels, e.g., in a graph overview.
This option renders a snapshot of the complete graph using WebGL.
In contrast to the pre-rendered image-based options, the snapshot is re-rendered every frame, thus producing good results for at all zoom levels.