[QUESTION] WASM backend

[pfeatherstone]

Hi, did you consider doing the processing of the "scene" in WASM then render by simply doing canvas.putImageData() ? All the drawing stuff could in principle be done in say C++, compiled to WASM using Emscripten, then plot/render using canvas? I'm wondering if that would be more efficient than using canvas itself for rendering? Dunno if you'd already considered or even tried this. PyQTGraph basically does this. All the "image processing" is done using numpy and scipy then offloads the rendering, i.e. the very last step, to QT. Otherwise, everything is done in numpy which is why PyQTGraph is so fast. In this case, all the processing, including decimating line graphs etc, could be done with a high performance library like Eigen, or a good Rust library. Maybe canvas is fast enough now that using WASM isn't worth it.

[michi42]

Not sure if it is work it. I have been using uPlot for a while in a scientific environment with tens of thousands of points updated a couple of times per second, and I made my own little python plotting library inspired by pyqtgraph and uPlot (because pyqtgraph is too opinionated in my opinion, the "barebones with plugins" approach of uPlot is just right 😀 ).

The key difference is that modern browsers' JS engines are crazy fast compared to cpython. In fact, they reach a performance similar to high-level compiled languages such as Rust do, and rendering operations on canvas can be offloaded to the GPU, which might well be faster than a custom CPU implementation.

[pfeatherstone]

Ok interesting. I've tried for example plotting a real-time waterfall plot on canvas and it simply couldn't reach the performance of pyqtgraph. Our applications are plotting live IQ data coming from an SDR. We've found doing it in canvas alone couldn't achieve the required performance. Hence the motivation of going down the WASM route.

[michi42]

I don't know how big or how fast your waterfalls are, but here is a little example extracted from one of my use cases: https://michi.web.cern.ch/tmp/uPlot/waterfall/

Of course waterfalls and 2D images are not really a core functionality of uPlot, so I have my own plugin to draw (and color-map) them.

Note this demo playing faster than real-time, the acquisition was at ~5 Hz, but this is replayed at ~20 fps to show it is possible; it eats ~30% CPU on my Firefox on Linux.

[pfeatherstone]

For line charts, i need to be plotting over 1 millions points at 30FPS. Does uPlot support min-max decimation ?

[leeoniya]

Does uPlot support min-max decimation ?

yes, it does a variant of minmax by default. more detail here: #1025

i need to be plotting over 1 millions points at 30FPS

this is probably pushing it, tbh. as i mention in the readme, you would be better off with webgl/webgpu for realtime signal plotting at these data sizes.

the main bottleneck is typically not the JS, but the rasterization, so WASM likely wont be much help here if it is expected to do antialiasing, line width > 1, opacity, and all the other things that Canvas does. if you're okay throwing away those things, there's for sure a lot to gain from webgl/webgpu, otherwise the only thing you may gain in wasm is moving the work off the main thread, and in this case it may be worthwhile looking at OffscreenCanvas support in uPlot, which is not trivial either, and may not be worth the squeeze (#733)

---

that's a really cool demo @michi42 , you could probably write out the entire pixel at once :)

https://jsfiddle.net/andrewjbaker/GhwUC/

var canvas = document.getElementById('canvas');
var canvasWidth  = canvas.width;
var canvasHeight = canvas.height;
var ctx = canvas.getContext('2d');
var imageData = ctx.getImageData(0, 0, canvasWidth, canvasHeight);

var buf = new ArrayBuffer(imageData.data.length);
var buf8 = new Uint8ClampedArray(buf);
var data = new Uint32Array(buf);

for (var y = 0; y < canvasHeight; ++y) {
    for (var x = 0; x < canvasWidth; ++x) {
        var value = x * y & 0xff;

        data[y * canvasWidth + x] =
            (255   << 24) |    // alpha
            (value << 16) |    // blue
            (value <<  8) |    // green
             value;            // red
    }
}

imageData.data.set(buf8);

ctx.putImageData(imageData, 0, 0);

[pfeatherstone]

The reason why I ask about min-max is because with chart.js for example it reduces my 1 million point line down to roughly 3000 points ( depends on size of screen etc ) then plotting becomes really fast. Min-max decimation on CPU using a SIMD library in c++ for example then compiled to WASM could potentially be a huge gain then. In my case, the min-max decimation is the most expensive part I think hence why I want to optimise that

[leeoniya]

uPlot's min-max decimation happens during path draw, which allows it to avoid allocating intermediate arrays. there's no need to guess how much it costs, you can simply profile it in the browser: https://leeoniya.github.io/uPlot/bench/uPlot-10M.html

for 2M points, this is the hot min-max-lineTo loop:

---

if you have an an end-to-end demo for data -> WASM-minmax -> canvas lineTo(s) that goes faster than this, i'll gladly look at it and give you my opinion.

[pfeatherstone]

Thank you for the discussion. I'm gonna give this a good test when I get back from holiday.

[michi42]

i need to be plotting over 1 millions points at 30FPS

this is probably pushing it, tbh. as i mention in the readme, you would be better off with webgl/webgpu for realtime signal plotting at these data sizes.

In fact I was curious, and to me it looks like if you use simple paths uPlot does just fine ...

If I modify your 2m points example to iterate through a few 2M points data sets at 25 Hz it, uPlot uses ~50% CPU and ~6 % iGPU on my machine (Intel Metorlake, Chromium and Firefox, on Linux):
https://michi.web.cern.ch/tmp/uPlot/waterfall/large.html

There is still some margin, painting takes ~20ms, so 30 fps is no problem, 60 fps (or whatever requestAnimationFrame() gives, with might even be faster) is pushed...

that's a really cool demo @michi42 , you could probably write out the entire pixel at once :)
https://jsfiddle.net/andrewjbaker/GhwUC/

Thanks 😄

I was thinking about writing uint32's in fact, but I think I'd need to use DataView to be independent of the platform endianess (although one could claim dominance of little-endian by now). Then in my tests I don't see a huge speedup from this, even if I pre-compute the colormaps as uint32 (to avoid per-pixel bit stuffing). I gain on the loop, but lose on allocation & writing pixels to ImageData.