Cool demo, but by the looks of things the whole site is rendered into a canvas element. As a result, the browser's dev tools are useless, it won't work with screen readers, and you can't copy+paste text. And any text rendering and input elements will be non-native. (So, no nice iphone controls. No native / system configurable keyboard shortcuts. And so on.)

I sincerely hope the web as a whole doesn't move in this direction. The inspectibility of the DOM is one of the web's greatest strengths. Lets not throw that away.

And scrolling is unavoidably all wrong: dragging two fingers from one end of my touchpad to the other should scroll by about four screenfuls, but only manages two thirds of one screenful; a quick swipe should send it dozens of screenfuls, with inertia, but manages even less than that two thirds of a screenful; and these limitations are fundamental due to the web not possessing the right primitives. (Then there are more fixable bugs like that, after focusing the page, you have to move the mouse before scrolling will work.)

And input element behaviour is non-native, which will never be properly fixable since different UAs have different behaviours, some of which cannot be emulated even if you sniff which platform you’re on (e.g. scroll bar grab and drag behaviour when you move far outside the window). (Then there are also simple bugs: holding Left or Right while the range element is focused only bumps the value once, not according to key repeat. And Up and Down don’t work.)

I have written about these things a number of times, fundamental limitations of the pure-canvas approach that make it unavoidably and permanently unsuitable. https://news.ycombinator.com/item?id=33861831 is probably the best thread.

(And just for a bit of fun: the demo can have slightly negative utilisation, drawing outside the box!)

In my testing, I went through a bunch of Rust frameworks that sit on top of the core OS UI frameworks. My experience with all of those was that they all capped out at about 3k rectangles on a screen at a time at 30 fps (vs the about 80k rectangles that fit at usually 30-60 fps in my demo).

I wonder if your experience is different?

As best I've been able to tell, right now you have to make a choice between (a) fast and (b) native, and you only get to choose one. And in my application domain, fast is nonnegotiable.

Mixed UIs could probably work well here. Using a canvas and specific gpu rendering just for the part requiring high throughput makes sense.

What domain are you working in?

Smoothly rendering 3k rectangles isn't a common use case for UI libraries, so I'm not surprised they perform poorly. They generally aren't optimized for that. The normal answer for weird, high performance rendering like that is to just use opengl or something and program against the GPU directly. 3d rendering contexts can render millions of rectangles on modern hardware without breaking a sweat.

This advice is the same on desktop, mobile or the web. I'm not surprised rust UI frameworks have the same limitation. Most UIs don't need thousands of rectangles. But they do need lots of custom widgets, and implementing all of those well is a higher priority job for anyone building a custom UI library.

Like I said in my top comment, it's a profiler. I need to consume logs from distributed applications (on possibly tens of thousands of nodes) and render them in as coherent a fashion as possible.

Going to 3d rendering via OpenGL / WebGL was one of the options I considered. But honestly, this is a boatload of complexity. Why do I need to pick up a full 3D rendering library just to draw rectangles on the screen? Plus, consider: the slot viewer (where the rectangles are shown) still needs to draw some UI components (e.g., on hoverover). I still need that UI integration there, even if it's not as performance-sensitive. So I end up needing something along the lines of egui anyway.

I definitely understand that not all UI libraries are going to be optimized for this. But I was surprised that it wasn't easy to e.g. get a high-performance canvas dropped into libraries that specifically advertised themselves as high-performance.

The reason to pick up a "a full 3D rendering library" is that it is actually a lower level interface to the hardware. Almost all 2D operations are now implemented on top of 3D hardware primitives.

By limiting yourself to a 2D engine you're ensuring there are more layers of abstraction between you and the hardware. While # layers of abstraction doesn't always correlate with overhead, it does place limits on performance.

Yeah. And it’s not one or the other. On the web you can make a “3d” rendering surface for the profile traces and use absolutely positioned DOM elements rendered on top for you hover-over widgets and things.

It’s still a bit of a mess though. I understand wanting to keep everything in a single UI library if you can.

I was curious so I took a look at firefox's profiler. It looks like it does a hybrid render, using a couple of canvas elements for the flame graph and the stack trace (up the top), but the rest of the UI is rendered using plain old DOM elements. It performs great, despite the whole thing being pure javascript.

Example: https://share.firefox.dev/40QUthv . (Though this trace is probably smaller than the profiling traces you're demoing.)

Should you be changing 3K rectangles of your interface at 30fps? This seems like a very narrow use case that should be restricted to using Canvas with very specific parts of the application.

Maybe you have graphs/charts that need that kind of rendering effect. Great, use Canvas for them, they're not accessible anyway. But if something like your main user controls are running into that problem, I feel like something has probably gone wrong with your user interface.

In the demo you linked, it makes a lot of sense to render to Canvas for the individual charts, flame charts, breakdowns. It does not make sense to me to render to Canvas for the sidebar. It doesn't make sense to me that the list element itself holding the charts is going through Canvas. That's something in your UI that honestly shouldn't be updating at the speed you're talking about.

I don't know if you noticed, but my test has on the order of 10 billion rectangles. Only about 80k are drawn on the screen at once because I do very aggressive culling.

To be honest, I'm not sure Canvas can handle either part of this: either drawing 80k rectangles at 60 fps or culling so that the other 10 billion don't need to waste CPU cycles. It requires a very tight integration with the UI library to make sure we do this fast.

Yes, it's a very narrow use case. That's why I went with a specialized UI library.

> I'm not sure Canvas can handle either part of this

To be clear, WebGL/WebGPU is still using Canvas. You're not using the 2D api stuff, but that's just a high-level API on top of Canvas. You're still rendering to Canvas.

> I don't know if you noticed, but my test has on the order of 10 billion rectangles

Why? I've built apps like this before. Your choice is not "abandon the DOM" or "have zero performance." You can have most of your interface in the DOM and use Canvas (again WebGL/GPU is still Canvas) for specifically the parts of your app that wouldn't be accessible anyway (mainly charts).

It does not require tight integration with the GPU to render the sliders on the left hand side of the screen in this demo. No one is saying that you need to render your charts in DOM. We're wondering why you got rid of `ul` elements.

If you build an equivalent tech demo in HTML Canvas, I'd be curious to see how it performs. I'm sure you're aware that, just because Canvas layers on top of WebGL/GPU draw calls, doesn't necessarily mean it's performant in the way I need it to be. There are many ways for performance to degrade across abstraction layers, even if in principle it shouldn't.

I didn't test Canvas specifically in my explorations, but I did test a few JavaScript based frameworks, and the ones I found that were efficient sat on top of WebGL, not Canvas. Ultimately I didn't pick those because they had a bunch of other stuff baked in that I didn't need or want, and were already equally non-native (sitting on top of WebGL). And I frankly didn't want to be writing JavaScript.

> just because Canvas layers on top of WebGL/GPU draw calls, doesn't necessarily mean it's performant in the way I need it to be

You are using Canvas right now. WebGL uses Canvas to render to the screen. If you open up your demo's DOM inspector right now, you will see a canvas element. It's:

  <canvas id="the_canvas_id" width="1914" height="580" style="width: 1914px; height: 580px;"></canvas>

It's a little bit hard for me to trust this kind of dismissive talk about the browser adding too many abstraction layers when it's not clear to me that you're fully aware of what browser features your demo is using right now. Targetting the DOM and using embedded canvases really doesn't have anything to do with whether or not you're writing Javascript, and it doesn't mean you can't use WebGL to render charts.

> You are using Canvas right now. WebGL uses Canvas to render to the screen.

Ehhh sort of. Canvas is much older than webgl. When we talked about canvas a few years ago, that always referred to the canvas DOM element and its associated 2D shape based API. (fillRect / moveTo / lineTo / etc). When Webgl appeared, the nomenclature was "using canvas" vs "using webgl", since webgl's API is completely different from the 2d canvas API.

But browser manufacturers didn't give webgl its own DOM element. Webgl also uses a canvas DOM element, then configures it differently. (getContext("webgl") instead of getContext("2d")). So if you're using webgl (which I think this app is doing), then you're "using canvas" in the sense that your HTML contains a <canvas> element. But you aren't using the canvas 2d API - which, as I said, is totally different from webgl and is also called "canvas" because it was here first. And it doesn't have another name.

In defence of the GP comment, I think its pretty clear from context that "Canvas layers on top of WebGL/GPU draw calls" refers to the canvas API, not the canvas DOM element.

Even in that context, it's not really accurate to say that Canvas "layers on top of WebGL"; WebGL targets the canvas element, it's not the other way around. And (correct me if I'm wrong) even when Canvas first came out, the 2D API was optional -- you could always take an array of pixels and render them onto a canvas directly and bypass all of the higher-level APIs. So I'm not sure it's ever made sense to call Canvas an abstraction on top of a graphical API, the graphical API was always a set of convenience methods around "put some pixels in this buffer."

If it's just a context misunderstanding of what specifically "Canvas" is referring to, fine, I don't mind clarifying what I mean by that. And you're right, it's not unreasonable for someone to see the word Canvas and think "2D APIs." But I just want to be very clear that targeting the DOM for UI controls doesn't mean you can't use WebGL or WebGPU and direct graphics programming for charts, or that you can't render a chart in a web worker and then use the pixel buffer with a canvas. And none of that stuff requires you to program in Javascript (except for glue code, which you'd have to write for all of those methods no matter what). In modern web terms when I talk about targeting the Canvas, I just mean rendering pixels onto a canvas element as opposed to manipulating the DOM, regardless of how or where those pixels are calculated.

There is no additional set of abstractions you need to go through to do that, and there's no graphical system for the web that gets rid of the singular abstraction of needing to eventually put the pixels onto a canvas element.

Yes, if you were calling browser 2D APIs, that would have an additional performance cost, definitely. In a context where that's not performant enough, then don't do that? But there seems to be a suggestion in this comment thread that embedding canvases would require working with a higher level more abstracted graphical API when rendering the charts, and that's just not true.

Maybe I'm misunderstanding you, but shouldn't this be the GUI toolkit's job, ie choosing what to render as native HTML vs what needs to rendered to canvas?

Can you recommend an alternative to egui that let's you write entirely in Rust and get the performance of egui but still maintain some level of accessibility?

> shouldn't this be the GUI toolkit's job

Ideally yes. This is a failing of the egui toolkit, not necessarily a failing of the people using it. The whole point of a high-level toolkit like this is that you shouldn't have to worry about how things are being rendered.

However, it is still important to counter claims that egui is making if the people using the toolkit are parroting those claims.

> Can you recommend an alternative to egui that let's you write entirely in Rust and get the performance of egui but still maintain some level of accessibility?

I don't think I've ever built a web GUI in Rust so I have no idea what the ecosystem looks like. To my detriment, I tend to build most of my UIs from scratch. I can promise that it is possible to have performant UIs with a lot of embedded charts (like this demo has) using the DOM, but I have no idea what Rust framework devs have been getting up to or publishing.

There's also a little bit of a catch-22 here because yes, any time you introduce the DOM, you are going to lose some performance. That doesn't mean that you're going to lose so much performance that the demo above would be stuttery or wouldn't work. But if you're just measuring "how many quads can I refresh on the screen", that's kind of missing the point that you really shouldn't be refreshing thousands and thousands of quads of information in a UI at 60fps. That's not a thing that most interfaces should be doing in the first place.

And if you are genuinely changing thousands of boxes of information on a screen at the same time, kind of by definition that isn't accessible period. There is no way to present that volume of informational change to a screen reader in a way that will be understandable. But a lot of people when building UIs tend to think they're in the rare cases where they need that level of performance and so they need to sacrifice that accessibility, when in reality what they actually have is a giant list of charts and aside from the actual chart rendering, there's nothing particularly expensive going on.

Well, in fairness web-based applications (including Electron ones running locally) break most of the inspectability benefits that came before, at least on the Windows platform.

eg. I used to be able to programmatically grab hWnd's (like Spy++ does), and manipulate the forms of an app. Apps used to show up as one (or two) simple processes with rich instrumentation metrics in tools like Resource Monitor.

Chrome abstracted all that away in an effort to 'displace' the OS.

I think canvas-only technologies could eventually do the same (the endless cycle continues) and look forward to some of the benefits (eg. more deterministic and straightforward positioning and layout). But I strongly agree they need to accommodate most of the features you mentioned and until they do it's two steps backward.

Do appreciate your thoughtful comment and the concise summary of some fundamental limitations that are presently hard barriers.

> Well, in fairness web-based applications (including Electron ones running locally) break most of the inspectability benefits that came before, at least on the Windows platform.

eg. I used to be able to programmatically grab hWnd's (like Spy++ does), and manipulate the forms of an app. Apps used to show up as one (or two) simple processes with rich instrumentation metrics in tools like Resource Monitor.

---

I disagree pretty hard with this sentiment. Yes, it's harder to programmatically interact with some of the browser features from outside of the browser. Programmatic interaction with basically any application that isn't yours is getting harder across every operating system as security becomes more important.

That doesn't really change that introspection of the source that makes up a displayed site was easy and approachable. I can look at the css/html/js. Further, all of those resources are contained in files intended to be opened and looked at by humans (they're human readable text).

This is my biggest issue with WASM. You're literally back at reading assembly again. And while that's possible, and there is tooling that can help - it's just not the same as being able to right-click on something, alter a couple of attributes in human readable words, hit enter and see that change.

> This is my biggest issue with WASM. You're literally back at reading assembly again. And while that's possible, and there is tooling that can help - it's just not the same as being able to right-click on something, alter a couple of attributes in human readable words, hit enter and see that change.

WASM on its own isn't the problem. WASM just lets you use another language to replace javascript. When you right click on something in a browser and alter human-readable attributes, you're usually messing with CSS and HTML. Any half decent web UI framework should pass HTML and CSS to the browser in order to render the UI. Thats just as true with wasm frameworks as it is with javascript frameworks.

The problem in this example is that the wasm code is bundling its own UI library that is trying (badly) to replace the browser's layout engine. All the browser can see is a bunch of drawing calls to an html canvas. Thats not the fault of wasm. Its just this UI library, which isn't really designed for the web.

Most web apps don't use human readable text. It's all heavily minified and the textual nature is just pure downside: slower and harder to parse than binary, more bloated, harder to implement.

I have no beef with deferred mode GUIs except that I have yet to see one with the performance characteristics I need.

For what it's worth, egui does have an accessibility layer. I haven't gone to any particular effort to wire it up yet (besides what you get by default): https://github.com/emilk/egui/issues/167

This is what I don't get: if you have an accessibility layer that is fully usable, that means you have the capability to describe your user interface using only speech/text.

So what are you doing that couldn't be performant in the DOM? Because any kind of fast updates that you're doing that's too fast to render in an XML tree is also going to be too happening too fast to describe with a screen reader?

The DOM is asking you to be able to describe your interface -- performantly -- in entirely pure text. If you can't do that, then there's no way you can be fully accessible, because the screen reader needs to be able to describe your interface -- performantly -- in entirely pure text.

People always get upset about this kind of thing, but it's very obviously true.

If you are updating thousands of rectangles in your UI at 30/60fps, it is impossible for you to fully convey the same amount of information that is changing visually to a screen reader.

Either your interface can be described using pure text, or it can't. Either I could use your interface by closing my eyes and having someone describe it to me, or I can't.

That's nothing new with immediate rendering... You can't have great performance and great usability. Not saying I prefer that way, just pointing out the obvious.

If the web API zoo wouldn't be so random it would all be easier. Pretty much all problems on the web (including the Javascript framework churn) are caused by the DOM being too high level, too inflexible and generally too 'black-boxy' to do anything interesting.

Accessibility could be fixed easily if there would be a web accessibility API. There's basically an entire 'middle layer' of web APIs missing, current APIs they are either low level (like WebGL/WebGPU) or too high level (like the DOM).

you're almost describing flash

i mean, it sucked, but it was kind of that middle layer.

> Accessibility could be fixed easily if there would be a web accessibility API

It does have one. The DOM is the web accessibility API. A really big point of the DOM is that you don't get to make multiple interfaces, you have to make one interface that works for everyone, which forces you to provide some degree of feature parity between those interfaces.

The web accessibility API is "you have to describe your interface to us in pure text, because that format is more likely to be accessible."

We could build a "DOM" inspector that runs inside the canvas too ;)

> I sincerely hope the web as a whole doesn't move in this direction.

I'm not happy about it, but I think it will.

> The inspectibility of the DOM is one of the web's greatest strengths.

Not if you're pushing ads.

Obligatory jaw-dropping egui demo:

https://www.egui.rs/#demo

Egui slaps and is clearly going places.

Got this to crash by change the font size in the font book demo.

Trying to copy/paste in safari also crashes the demo.

"Loading..."

I've run it before. I know what it looks like.

I use egui. It's OK. But you have to code up all your dialog boxes in Rust. This is misery if you have fifty dialog boxes and widgets you need. The widget library is weak and the themes are poor. I don't care, because I'm doing a metaverse client, and all the visuals are in the 3D image. The 2D GUI on top is minimal, as is normal for games. So minimal that it disappears completely, like YouTube controls, when you're not using it, to give you a clean 3D world.

(Egui hint: don't use bottom-up layout. Always work top-down, left to right. Egui layout is one pass, and while it tries to look ahead, it's not good at it.)

It's pretty lagging for me on a beefy machine with hardware acceleration enabled. What gives?

Are other WebGL demos also slow (e.g. check https://webglsamples.org/)? How uptodate are your graphics drivers? In some rare cases WebGL is blacklisting old drivers if they have known vulnerabilities, and instead falls back to software rendering.

egui is nice for internal tools, and for quickly creating UIs for games and such, but I don't think I'd ever release a consumer-facing app with it. It has too many quirks compared to a more "native" UI that it can be quite awkward to use interfaces made with it. I'm talking about things like inertial scrolling, text selection, window resizing, etc.

It's certainly nice to work with from a developer's perspective, what could be easier than

    if ui.button("Say hello").clicked() {
        println!("Hello!");
    ]

?

But it's quite a pain to style if you're particular about typography and pixel-perfect layouts. Between styling an egui app and styling something with CSS (or some flexbox/grid system), I'll take CSS every time.

Still looking forward to how Xilem turns out, and what people build on top of that.

For this there's Leptos and a half dozen other "DOM in Rust" frontend frameworks:

https://github.com/leptos-rs/leptos

These are already orders of magnitude faster than React, and as the WASM<->DOM bridge improves, they will only get faster.

Sycamore:

https://github.com/sycamore-rs/sycamore

https://sycamore-rs.netlify.app/examples/todomvc/#

Dioxus:

https://dioxuslabs.com/

In about 3-5 years these frameworks will start to consolidate and reach maturity.

It's already possible to build reactive isomorphic apps in Rust.

If you haven't checked out Actix/Axum, it feels a lot like Python/Flask. The ecosystem is coming along quickly.

Yep, my current favorites are Axum and Dioxus for web things (and some desktop apps too).

That looks awesome - are there any accessibility features (e.g. supporting screen-readers)?

Yes! egui uses https://github.com/AccessKit/accesskit for accessibility

Are you being sarcastic?

I certainly was extremely impressed the first time I saw it. Other than the font book I haven't found anything there that is slow. What makes you think the op might have been sarcastic? Egui was in a thread yesterday and it seems like canvas rendering is a dividing issue between people who value portability and performance most vs people who value consistency of ergonomics and style/look most.

Its certainly controversial. Using canvas based rendering like this is essentially reverse-electron.

Electron builds native software by embedding a web browser and using the browser's layout engine and DOM. Canvas based rendering like this is the inverse. Here the application discards the browser's layout engine and DOM, and instead embeds its own layout engine. - Despite the browser being right there and available.

Hilariously, in a demo like this there's 3 layers of UI controls nested inside each other. First, there's the OS's native UI toolkit. Then there's the browser. The browser discards most of those UI elements, and reimplements its own controls. And then Egui discards all of that and embeds its own, third layout engine all written in wasm. No inertial scrolling. No web inspector. No native controls (especially a problem on iOS or android). No CSS - so I hope Egui's layout engine supports the layout you're after.

Downside: Its a 5mb wasm bundle. But on the plus side, 5mb is positively tiny compared to shipping electron!

The idea is that instead of shipping electron, you ship a native binary that use egui without using wasm or the canvas.

Egui only use wasm in situations where you must use the user browser because you have no choice. Eg: showing a demo of the app on the web without having to install anything.

> Its a 5mb wasm bundle. But on the plus side, 5mb is positively tiny compared to shipping electron

This comparison makes no sense. Situation where electron could be used are exactly the kind of situations where a wasm bundle would not be shipped (a native binary would be shipped instead)

> This comparison makes no sense. Situation where electron could be used are exactly the kind of situations where a wasm bundle would not be shipped (a native binary would be shipped instead)

Sure; but given the insane size of shipping chrome, it’s fun seeing a full app complete with widget library, layout engine and text input elements in 5mb. It’s terrible to make websites that big. But if chrome could do all that stuff in only a 5mb binary then I’d be much happier with electron.

If you didn’t catch it, the wasm bundle is running in a 32mb memory slab. Positively slim by the standards of modern gui apps!

I'm curious to see if they took every effort to strip that demo down or not. I think eframe doesn't get a ton smaller than 2mb no matter what you do, so maybe they did.

I am working in vr on nreal glasses; this demo made me almost barf in my coffee. Everything looks like i'm having a stroke. Not sure why that is, but jaw dropping is it is not.

The first thing I noticed here is that the textbox doesn't have the usual context menu with commands like "Select all" and various IME features. It's not clear whether RTL and bidirectional capabilities are there, and if so, how to use them.

Next I clicked on the combo box, it opens the dropdown, and I try to use arrow keys to navigate it. That doesn't work. Is that because I opened it using the mouse? Nope, still doesn't work if you tab through the widgets and use Enter to open. Looking up items by typing the first few characters doesn't work, either.

This is all really basic stuff that native widgets offer to any app for free on any platform.

Thanks!

I don't like how those textboxes get bigger when you click into them.

What makes egui so fast? I thought immediate mode GUIs have a convenient API at the expense of unnecessary redraws and lower performance.

Would it be faster than iced or Slint at rendering scrollable list with thousands of rows with images and text? For the sort of use case you’d use a “virtualized list” implementation for React for example.

This demo produces only a handful of draw calls to the GPU, and even though those draw calls can have hundreds of thousands of triangles, that's still as efficient as it gets.

I guess that egui works similar to Dear ImGui: only (font) texture changes and clip regions (e.g. scroll areas) require a new draw call, and that's typically just a handful to a few dozen draw calls even for complex UIs.

For long lists, Dear ImGui has a special 'ListClipper' class which allows to iterate over the visible 'slots' of a list, so that the code which describes the list UI can skip clipped items early. Not sure if egui has something similar.

> Dear ImGui has a special 'ListClipper' class which allows to iterate over the visible 'slots' of a list, so that the code which describes the list UI can skip clipped items early. Not sure if egui has something similar.

An egui ScrollArea can request only visible rows from a callback using show_rows:

https://docs.rs/egui/latest/egui/containers/scroll_area/stru...

Also try mouse-wheeling in Tracy web version (using Dear ImGui) and opening different panels: https://tracy.nereid.pl/ I think you'll find it to be more reactive and snappier than most traditional toolkits.

I understand that this is a demo, but actually drawing all 8,000 nodes instead of just 3 screenfuls (6 nodes on my screen) and updating them dynamically when scrolling isn't what I would call 'performant', but needless waste of resources.

Btw: when clicking any 'task' to get to see the details, I see a repeating pattern of almost vertical stripes in some colors. I guess that's not what it should look like.

If drawing all 8000 nodes consumes less resources than rendering your average homepage, is it really wasteful? I understand it can be optimized, but that optimization often comes at a cost which may end up being even more wasteful.

Yeah, when a gpu is involved it is often cheaper to process everything rather than check what meeds to be processed.

I don't know how egui or the OP's app works, but we aren't talking about costly intersections of arbitrary surfaces but the sending of vertex data (for the vertex shader) in an integer interval (of nodes). This isn't about half or 1/10, but about 1/1000th of the data.

> If drawing all 8000 nodes consumes less resources than rendering your average homepage, is it really wasteful?

That may not have been clear, but I am talking about drawing less nodes in any case, also when using egui.

In Spector.js it looks like the demo is using a very small number of draw calls, and those can sometimes have hundreds of thousands of triangles. For old low-end mobile GPUs this might start to become a problem, but it's nothing for the last 20 years of desktop GPUs.

In any case, it looks like a good base for further optimisation to ignore offscreen UI elements early (e.g. not sure if egui has something like Dear ImGui's ListClipper).

wow, i am genuinely impressed! super snappy. I wonder whether it could be used to tackle a real pain point of mine. I work a lot with data, visualisations with jupiter notebooks. There are essentially two approaches: matplotlib, which outputs pngs/svgs. The notebooks stay fast but they are not interactive. The other is approaches like plotly, js-based, interactive, very useful but it gets slow really fast. I can not handle a lot of data. It can not handle a lot of plots. A simple, interactive plotting library with a focus on speed would be immensely useful! With python bindings. Could be a fun weekend project. I don't know any rust though, anybody up to collaborate? :P

I bet the canvas approach would not slow-down the notebook.

Try dear-imgui + implot. There are Python bindings

Checkout fastplotlib, which should be quite capable of what you're after and it works great in a Notebook https://github.com/kushalkolar/fastplotlib

Alternatively, try pygfx for ThreeJS graphics in Python leveraging wgpu. It works great in Notebooks through notebook-rfb. https://github.com/pygfx/pygfx

If you're adventurous, figure out how to make pygfx work with webgpu via wasm

It sounds like you want BokehJS. It was one of the alternatives I was recommended while I was exploring, but for various reasons my particular use case is not so easy to integrate (plus my backend was already in Rust).

https://github.com/bokeh/bokeh

I did do a basic test, and the raw rects-on-screen performance is roughly comparable to my final solution.