WebGL Rendering

In addition to SVG and HTML canvas rendering, yFiles for HTML offers WebGL and WebGL2 rendering. This technology provides superior performance for rendering lots of simple, similar items, making it suitable for displaying very large diagrams (e.g. "hairball graphs"). The downside is a more limited set of predefined styles and the lack of label styles, as text rendering is very expensive when using WebGL. Also, implementing custom WebGL visualizations is much more complicated compared to SVG or canvas styles.

To see WebGL rendering in action, have a look at the Rendering Optimizations demo.

While WebGL is a reliable web standard for 3D graphics rendering, yFiles for HTML WebGL rendering support has certain limitations compared to the improved WebGL2. Unless there are specific compatibility requirements with older browsers, we strongly recommend using WebGL2 for better rendering capabilities and performance.

Predefined WebGL Styles

yFiles for HTML comes with the following predefined WebGL styles:

WebGLShapeNodeStyle

This is the WebGL variant of the ShapeNodeStyle, offering a selection of basic shapes for node visualizations.

WebGLImageNodeStyle

This is the WebGL variant of the ImageNodeStyle, which can display an image. Note that the image has to adhere to the same-origin policy (otherwise a blue rectangle is used as a fallback).

WebGLPolylineEdgeStyle

This is the WebGL variant of PolylineEdgeStyle.

WebGLTaperedEdgeStyle

This edge style draws a simple tapered line from the center of the source node to the center of the target node (both bends and ports are ignored). Very performant.

The WebGL Rendering API

In general, we advise against implementing custom item styles that use the WebGL rendering API, as it is hard to use the WebGL rendering pipeline efficiently from within the yFiles for HTML rendering engine. WebGL visualizations should rather be used for standalone visuals — e.g. background visuals, graph overlays, or custom high performance visualizations of the whole graph structure.

Styles or renderers which use the WebGL API have to implement their createVisual method to return a Visual which is a subclass of the abstract WebGLVisual. Implementations of WebGLVisual have to implement the render method.

class GraphBoundsVisual extends WebGLVisual {
  /**
   * Draw a simple rectangle as large as the content bounds.
   * @param {IRenderContext} renderContext
   * @param {WebGLRenderingContext} gl
   */
  render(renderContext, gl) {
    const program = renderContext.webGLSupport.useProgram(
      `
      attribute vec2 position;
      void main() {
        gl_Position = vec4(u_yf_worldToWebGL * vec3(position, 1), 1);
      }
    `,
      `
      precision mediump float;
      void main() {
        gl_FragColor = vec4(0, 0, 0, 1); // black
      }
    `
    )
    if (!this.buffer) {
      this.buffer = gl.createBuffer()
      this.vertexBuffer = new Float32Array(8)
    }

    const contentRect = renderContext.canvasComponent.contentRect

    this.vertexBuffer[0] = contentRect.x
    this.vertexBuffer[1] = contentRect.y
    this.vertexBuffer[2] = contentRect.x + contentRect.width
    this.vertexBuffer[3] = contentRect.y
    this.vertexBuffer[4] = contentRect.x
    this.vertexBuffer[5] = contentRect.y + contentRect.height
    this.vertexBuffer[6] = contentRect.x + contentRect.width
    this.vertexBuffer[7] = contentRect.y + contentRect.height

    gl.bindBuffer(gl.ARRAY_BUFFER, this.buffer)
    gl.bufferData(gl.ARRAY_BUFFER, this.vertexBuffer, gl.STATIC_DRAW)
    gl.enableVertexAttribArray(gl.getAttribLocation(program, 'position'))
    gl.vertexAttribPointer(gl.getAttribLocation(program, 'position'), 2, gl.FLOAT, false, 0, 0)

    gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4)
  }
}

There are several predefined uniforms which are passed on to the shader automatically if they are used in the shader source. The matrices generally correspond to the transformations described in projections, with an additional ToWebGL-Transformation component that accounts for WebGL having the coordinate origin at the center and normalized axis in the range [-1..1]. This transformation is also separately available as u_yf_viewToWebGL and its 3D counterpart u_yf_viewToWebGL_3d.

The render method is called upon each repaint. Its gl parameter is the WebGL context (canvas.getContext("webgl")) for the canvas to paint on.

Using the WebGL API for zoom-dependent, high-performance rendering is presented in the Rendering Optimizations demo.

When should I use WebGL rendering?

WebGL rendering has advantages for the following use cases:

• very large diagrams
• simple rendering
• complex procedural graphics or particle effects

If your use case fits within the above parameters, we highly recommend using WebGL2 Rendering instead of WebGL, unless there are specific reasons for sticking with WebGL (such as compatibility with older browsers). Using WebGL2 Rendering provides better performance and improved features, making it the preferred choice.

WebGL rendering is best for rendering many elements with a simple visualization. In other words, for very large diagrams with few details. When compared to canvas rendering, WebGL rendering offers even better performance and comes with a selection of predefined styles. However, it requires greater effort to implement custom WebGL visualizations that render efficiently and Internet Explorer 9/10 doesn’t support WebGL rendering.

A typical use case for WebGL rendering is zoom-level dependent rendering (level-of-detail rendering): For low zoom levels, when the number of visible elements is high and a simple visualization is sufficient, the style renderer provides a WebGL-based rendering whereas at higher zoom levels, it uses more sophisticated SVG-based styles (for example with fine details, gradients, drop shadows, etc.).

When should I avoid WebGL rendering?

WebGL rendering will not work at all, or at least might perform badly, in the following use cases:

• Wrapping or decorating graph item styles: All style decorators are SVG-based and expect that a decorated style creates a visualisation that consists of an actual SVG element. Although WebGLVisual extends Visual it doesn’t provide such an element. Thus, decorating styles which provide WebGL rendering will fail.
• Mixing SVG-based styles and WebGL-based styles: yFiles for HTML provides a hybrid rendering mechanism. It can render both WebGL-based styles and SVG-based styles at the same time. Internally, WebGL visuals are drawn on one canvas if possible. If an SVG style is drawn in between WebGL-based styles (with respect to their z-order) the styles behind the SVG are drawn on one canvas and the ones before are drawn on another canvas. Mixing canvas and SVG-based styles might thus result in generating a large number of canvas elements which will have a negative impact in memory consumption and performance. Note that nodes, edges, labels and decorations like handles are drawn on separate layers, thus mixing a WebGL-based node style and a built-in label style won’t be a problem, for example.
• Complex painting: Since the canvas has to be completely re-rendered at each repaint, a too complex rendering might reduce the performance compared to SVG-based rendering. Another drawback of WebGL rendering is the handling of native mouse and touch events: the canvas will either catch all of these events or let them pass through. In the first case, SVG elements won’t get hover effects if a canvas level is drawn in front. In the latter case, you will get hover effects even for elements which are hidden behind a canvas node. Note that the mouse and touch events provided by the CanvasComponent are not affected.