Fastplotlib: GPU-accelerated, fast, and interactive plotting library • Hacker News Board

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#171

Post by jarpineh » Wed, Mar 12, 2025, 1:11 PM UTC

This looks very promising. I'll have to think my visualization cases against new possibilities this enables.

I have been intermittently following Rerun, a "robotics-style data visualization" app [1]. Their architecture bears certain similarities [2]. Wgpu in both, egui and imgui, Rust with Python. Rerun's stack does compile to WASM and works in browser. Use cases seem different, but somewhat the same. I don't do scientific nor robotic stuff at all, so no opinions on feasibility of either...

[1] https://rerun.io [2] https://github.com/rerun-io/rerun/blob/main/ARCHITECTURE.md

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#172

Post by neomantra » Wed, Mar 12, 2025, 2:00 PM UTC

insane_dreamer wrote: post #167

Looks great--and meets a significant need. I see you have meshes on the roadmap--very much looking forward to testing that for real-time cortex mapping once available. Kudos.

I'm exploring something akin to this, but focusing on 3D views via mesh shading, also powered by DuckDB.

Can you describe your cortex mapping data sources (volumetric? approx number of samples?) and is there any open data to grab? What kinds of visualizations/manipulations you would want or is there an existing product to compare to? Thanks :)

EDIT: Confused WGPU with WebGPU, so deleted a sentence.

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#173

Post by jampekka » Wed, Mar 12, 2025, 2:07 PM UTC

fransje26 wrote: post #170

jampekka wrote: post #158

Earlier quoted context omitted.

What are your issues with the matplotlib API more specifically?

Complaining about the inconsistencies of the matplotlib interface is pretty much beating a dead horse by now, and has been done repeatedly and in detail by others. The problems start as soon as you try doing something more than plt.plot(), and you get your first encounter with the maddening interface differences between a single figure plot and a multi-figure plot. And then it spirals out of control from there. There…

Sure there are some inconsistencies and legacy, but I wouldn't call that "horribly broken".

You're probably referring to plots with subplots. Those indeed have issues, although mostly not because of the API. This has somewhat improved with the constrained layout, within the old API. There's also now GridSpec for more control. And for EDA those don't really matter much. There are some annoying differences when calling Axis methods vs the global functions (e.g. xlim vs set_xlim).

Tweaking plots exactly as you want can get tricky, although for that the artist API can get you more or less anything you want. Care to share what's the library that gives you guaranteed results in no time and with no frustrations?

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#174

Post by [deleted] » Wed, Mar 12, 2025, 2:10 PM UTC

clewis7 wrote: post #56

CreRecombinase wrote: post #12

Every two weeks or so I peruse github looking for something like this and I have to say this looks really promising. In statistical genetics we make really big scatterplots called Manhattan plots https://en.wikipedia.org/wiki/Manhattan_plot and we have to use all this highly specialized software to visualize at different scales (for a sense of what this looks like: https://my.locuszoom.org/gwas/236887/ ). Excited to…

Hey! This sounds like a really interesting use case. If you run into any issues or need help with the visualization, please don't hesitate to post an issue on the repo. We can also think about adding an example demo of a manhattan plot to help too!

[deleted]

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#175

Post by stackedinserter » Wed, Mar 12, 2025, 2:55 PM UTC

dcl wrote: post #141

I always thought it was interesting that my modern CPU takes ages to plot 100,000 or so points in R or Python (ggplot2, seaborn, plotnine, etc) and yet somehow my 486DX 50Mhz could pump out all those pixels to play Doom interactively and smoothly.

Nobody cares about optimization for relatively big datasets like million points, maybe it's not a very popular use case. Even libraries that do able to render these datasets, do that incorrectly e.g. skip peaks, show black rectangles instead of showing internal distribution of noisy data, etc.

I ended up with writing my own tool that's able to show millions of points and never looked back.

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#176

Post by stackedinserter » Wed, Mar 12, 2025, 3:07 PM UTC

enriquto wrote: post #118

That would be preposterous if it wasn't so hilariously false: > These days, having a GPU is practically a prerequisite to doing science, and visualization is no exception. It becomes really funny when they go on to this, as if it was a big deal: > Depicted below is an example of plotting 3 million points Anybody who has ever used C or fortran knows that a modern CPU can easily churn through "3 million points" at more…

You can't draw a proper plot with 3 million points at 30 fps, unless you cut corners, like not showing distribution of data (showing black rectangle when there's internal structure) or skipping peaks, like many plotting tools do, e.g. Grafana.

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#177

Post by kushalkolar » Wed, Mar 12, 2025, 3:35 PM UTC

wodenokoto wrote: post #142

How is it compared to HoloViz?[1] I followed one of their online workshops, and it feels really powerful, although it is a bit confusing which part of it does what (it's basically 6 or 7 projects put together under an umbrella) [1] https://holoviz.org/

Fastplotlib is very different from bokeh and holoviz, and has different use cases.

Bokeh and holoviz send data to a JS front end that draws (to the best of my knowledge), whereas fastplotlib does everything on the python side and uses jupyter_rfb to send a compressed frame buffer when used in jupyter. Fastplotlib also works as a native desktop application in Qt and glfw, which is very different from bokeh/holoviz. Fastplotlib also has higher raw render speed, you can scroll though a 4k video at 60Hz with thousands of extra objects on your desktop which I haven't ever been able to accomplish with bokeh (I haven't tried it in years, not sure if things have changed)

The events system is also very different, we try to keep the API to simple function callbacks in fastplotlib.

At the end of the day use the best tool for your use case :)

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#178

Post by kushalkolar » Wed, Mar 12, 2025, 3:40 PM UTC

vegabook wrote: post #151

Syntax looks matplotlib-ish so we’re going back to 2003

Take a look at the examples gallery, it differs greatly from matplotlib. But I guess that will be subjective

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#179

Post by kushalkolar » Wed, Mar 12, 2025, 3:42 PM UTC

insane_dreamer wrote: post #167

Looks great--and meets a significant need. I see you have meshes on the roadmap--very much looking forward to testing that for real-time cortex mapping once available. Kudos.

In the meantime you can use the rendering engine pygfx to create them directly :)

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#180

Post by enriquto » Wed, Mar 12, 2025, 3:54 PM UTC

stackedinserter wrote: post #176

enriquto wrote: post #118

That would be preposterous if it wasn't so hilariously false: > These days, having a GPU is practically a prerequisite to doing science, and visualization is no exception. It becomes really funny when they go on to this, as if it was a big deal: > Depicted below is an example of plotting 3 million points Anybody who has ever used C or fortran knows that a modern CPU can easily churn through "3 million points" at more…

You can't draw a proper plot with 3 million points at 30 fps, unless you cut corners, like not showing distribution of data (showing black rectangle when there's internal structure) or skipping peaks, like many plotting tools do, e.g. Grafana.

Of course you can! The screen of my laptop has nearly 3 million points (2160x1350) and I can do a fair amount of processing on each of its pixels, with one CPU thread, and still be above 30fps. A naive plotting method that loops over all the points and puts them into a grid will work without problem. Try it yourself!