Curious about your fastplotlib performance

[kushalkolar]

Hi! I couldn't find your email so I thought I'd reach out here, I saw @pperanich doing some cool stuff in a fastplotlib fork for better line-stack performance. I'm curious what the performance gain is, we've mostly resorted to heatmaps when we have too many lines but it would be nice to have better line performance in general. I've wanted to try a single-buffer approach but didn't get around to it.

[pperanich]

Hi @kushalkolar !

Yeah, I’ve been poking at this in my fork because I ran into the same general problem with stacked traces.
The current line_stack example is nice for static display, but it still fundamentally builds a collection of individual line graphics. If you want to update a large stack at high rates, you end up iterating over each line graphic and updating each corresponding buffer separately (as opposed to single-buffer approach). For a modest number of lines that is fine, but once you get into dense multichannel / signal-view territory, the per-line object overhead and per-buffer update loop start to become the bottleneck.

What I’ve been experimenting with is a MultiLineGraphic that packs many lines into a single positions buffer, with NaN separators between lines, so the whole stack is represented as one line object instead of many.

For the streaming case in particular, I added a compact y-buffer path and an append/scroll mode so that when x is shared, updates can be expressed as “replace the newest y samples” rather than rewriting the full packed geometry every frame.
One slightly hacky part of the experiment is how I handle line separation. I wanted a way to visually separate lines without permanently baking arbitrary offsets into the raw data buffers, because for high-rate updates that just creates more data churn than necessary. So instead of adding offsets directly into each line’s y data, I used the z coordinate as a per-line offset channel and then applied a shear transform so the rendered y becomes effectively y + z * scale.

I mostly wanted to see whether that separation model would let me keep updates cheap while still getting a stacked-trace view. If there is a cleaner way to express “separate these lines visually without mutating the underlying signal buffers”, I’d be very interested in that too. We could likely do this with custom shaders (maybe upstream to pygfx), but I liked the idea of using the standard shaders that pygfx provides.

I did end up making a small pygfx change to support this cleanly. My first pass carried a forked copy of the line WGSL, which I was not happy with. So I added a small line-shader hook upstream in my pygfx fork that lets a downstream shader override logical node access / remapping without forking the whole line shader. That made it possible for the fastplotlib side to implement the multiline scroll/remap behavior much more cleanly.

The branches I’ve been working in are:

• fastplotlib: https://github.com/pperanich/fastplotlib/tree/feature/multi-line-graphic
• pygfx: https://github.com/pperanich/pygfx/tree/line-shader-hook

I have a couple examples for more context:

• https://github.com/pperanich/fastplotlib/blob/feature/multi-line-graphic/examples/line_collection/multi_line_ring_scroll.py
• https://github.com/pperanich/fastplotlib/blob/feature/multi-line-graphic/examples/line_collection/multi_line_single_buffer.py

As a side note, I've been using fastplotlib for quite some time and really enjoy it, thanks for your work! For one example, see https://github.com/ezmsg-org/ezmsg-qt/blob/main/examples/spatial_carrier_fft_demo.py

I'm happy to move this to an issue within fastplotlib as well.

[kushalkolar]

Hi thanks for all the details! We can do some tweaks and generalizations to merge this in fastplotlib.

single positions buffer, with NaN separators between lines

Yea that's what I would do as well.

If there is a cleaner way to express “separate these lines visually without mutating the underlying signal buffers”, I’d be very interested in that too.

There's a way to have a custom shader directly with fastplotlib, Almar would be the best person to ask about this. There might be a way to modify the existing shaders a bit to do this. I'm happy to do a call next week to chat about it

[kushalkolar]

@pperanich can you email me and we can look at integrating this into fastplotlib, my email is on my github profile, I have some availability next week

[kushalkolar]

@pperanich Just pinging you again, I'd like to get some version of this into fastplotlib ASAP if there's a significant performance benefit (I'm guessing there is?, what have you seen in benchmarks?). We're also writing a large paper on fastplotlib for neuroscience and happy to have you as one of the co-authors if this lands in fastplotlib.