Working with WebGL inside Exaptive is a great way to deal with large amounts of data in a visualization using the GPU. It takes some more work to craft a quality visualization in WebGL, but the payoff is typically worth the work if performance was a bottleneck using something like D3. What should you expect while working with WebGL inside Exaptive? That depends. "Working with WebGL" could mean anything from working with ThreeJS or pathGL to the native WebGL API. I'll try to list out some general thoughts, but each WebGL library/abstraction has different methods to manage your graphics environment, so these points may apply to you in varying degrees.

Here is a small demo I created inside the Exaptive platform. It uses a grid of triangle strips, then using only a timestamp, x, and y, transforms the plane inside the vertex shader to make a living surface.

Wobbly Flames Grid from Mark Wissler on Vimeo.

General Thoughts

1. Be mindful of the render cycle and the dataflow.

If your render cycle is running at an interval of 16ms and something in the dataflow happens to bind the event loop up for a while, your rendering will be laggy and the dataflow will be impacted as well since the renders will be interjecting while a xap tries to crunch data. I've had good luck with figuring out which inputs will require a render so that we render on demand instead of constant re-rendering. For example, render on data change, render on camera movements, render at 16ms if and only if there's an animation playing, and so on.

2. Don't hand strictly typed arrays between components.

We don't have support for handing native JS typed arrays. So keep the typed arrays local to the component(s) that need them. For example, if you wished to have one component procedurally construct vertices for a sphere, you should not try to send them as a Float32Array. Instead, send them as a vanilla JS array, then, on input to the rendering component, cast them however you'd like.

3. In general, don't use a ClearColor, or at least make it configurable.

This gives your visualization a background, and depending on the context of the visualization, a user might wish to use a non-solid color as a background for the visualization. Let the xap builder do that with html or css.

4. Rate limit or debounce your render function.

If you do render on-demand, then you may run into performance issues for extremely rapid rendering. For example, if on mouse move, you adjust the camera, send a camera matrix, then render, this can happen much more quickly than the typical 16ms render rate. This can quickly degrade performance, so in this case, we'd want to debounce the mouse move function such that we only render every 16ms.

Open Design Questions

1. Should cameras/interaction layers exist as a separate component from renderers?

On the one hand, it seems interesting and convenient to think about having the option for swapping an orthographic camera component for a projection camera component, or locking a camera into 2d motion in a specific z-plane. This makes for a nice separation of concerns and makes the dataflow more intuitive to look at and explain. However, by going through the dataflow for raycasting, model-view, and projection matrices, do we lose any performance?

The alternative is to build the camera/ui listeners into the visualization component. The more flexible the camera, the more inputs we'll need (which adds to the complexity of what might be a simple scatterplot visualization.) Further, the camera code inside the component can add a lot of overhead to the number of lines of code. This doesn't seem like much at first, but as a visualization component evolves, small amounts of code add up quickly to create a much more monolithic component. However, the performance gains by not having to receive a vanilla JS array and type cast it may outweigh this detail (#2 in general thoughts.)

2. How do I upload and work with my textures in the easiest way possible?

It is unclear how we will store textures and relate them to components at this time. Obviously you can always use a static asset hosting solution (S3) but it's unclear if this is the most convenient for a WebGL developer.