This is really cool! The toolbar requires imgui, was easy to get it working by just adding "imgui_bundle" to the deps. Was able to run stuff in chrome after enabling the wgpu experimental features. Firefox gave RuntimeError: WebAssembly stack switching not supported in this JavaScript runtime. Some examples that use uint8 don't work but this is a great start 🥳

The toolbar requires imgui, was easy to get it working by just adding "imgui_bundle" to the deps.

The way micropip resolves dependencies is a little odd to me, especially when you use .whl instead of a wheel on the index. Like the order matters for version conflicts etc. I saw imgui examples working, but that's due to a pyodide helper. I will add imgui_bundle to the list of deps there. Which might not be needed for every single example anyway.
I think it's also an option to require imgui when sys.platform == "emscripten" in the pyproject.toml

Firefox gave RuntimeError: WebAssembly stack switching not supported in this JavaScript runtime.

JSPI is used by pyodide to await an async function, it's used for the wgpu-py mappings. Looks like it's still worked on for Firefox. I don't think moving pygfx to all async would drop that requirement... not sure.

Some examples that use uint8 don't work

Can you share which examples caused errors for you? I can look into if they are are an issue in my wgpu changes that needs fixes.

Firefox gave RuntimeError: WebAssembly stack switching not supported in this JavaScript runtime.

JSPI is used by pyodide to await an async function, it's used for the wgpu-py mappings. Looks like it's still worked on for Firefox. I don't think moving pygfx to all async would drop that requirement... not sure.

This is the full traceback I get on firefox, maybe I can try updating.

Some examples that use uint8 don't work

Can you share which examples caused errors for you? I can look into if they are are an issue in my wgpu changes that needs fixes.

I got it in the ndwidget branch, but that might be because we recently allowed direct uint8 textures there. But in main the colormap picker doesn't show up when you right-click the colorbar in the image_widget/image_widget.py example. I wonder if it's an issue with the wgpu texture upload. It's basically this wgpu-imgui example: https://github.com/pygfx/wgpu-py/blob/main/examples/imgui_cmap_picker.py

the colormap picker doesn't show up when you right-click the colorbar in the image_widget/image_widget.py example. I wonder if it's an issue with the wgpu texture upload. It's basically this wgpu-imgui example: https://github.com/pygfx/wgpu-py/blob/main/examples/imgui_cmap_picker.py

ah, that was one example I never tried in wgpu-py and it also had this issue (it spews your browser console with a sorta helpful message). I pushed a commit that fixes the behaviour. But I think there might be an actual problem with how we transform data from python to js (some dimension of the shape might be lost), as the default (no args) for .create_view() seems to behave as expected natively but not in the browser.

I will look into that later, thanks!

I wonder what performance we can get with compute shaders here, like what's the overhead. When I get a chance I want to try running this stuff on it: https://github.com/kushalkolar/wgpu-sparse-matvec

I am currently seeing about 20% performance compared to native when you look at framerates. But there is a lot to that. Moving data is probably the worst right now since it's doing 3 or more copies. And scheduling as issues because of the waiting and being driven by the browser framerate too.
There should be very little overhead once you run compute on the GPU. Because it's the same GPU you would use native. But might be fun to measure it.

I think one limitation with wasm is 2GB of memory. But not sure if that applies to resources on the GPU

Not a webdev so the styling is all awful - but this works locally when I built the docs (plenty of issues with duplication for example). And the imgui cmap picker works!

I didn't want to mess the ci job for docs preview but I think it could work. Let me know if that is something I should try

(also found additional issues for myself, something about unmapped buffers in the surface_ripple example).

Hi! Dear ImGui Bundle author here (@Vipitis and I have talked on the bundle discord).

First, congrats on this effort! Having worked on a similar approach, I know that this is a very complex endeavor.
I'm not a fastplotlib dev, but since this PR can also use imgui_bundle under Pyodide, I thought I'd share some of the lessons I learned while working on creating a dedicated pyodide runner for imgui bundle's own runners.

Main suggestion: reuse the Pyodide runtime between examples instead of calling loadPyodide() per page. Most of the per-example wait is not downloading the wheels (those get cached) but re-installing them into the fresh in-memory filesystem and re-initializing the interpreter. In the imgui_bundle playground (https://imgui-bundle.pages.dev/playground/), all demos share one runtime (and one canvas in my case): switching demos is near-instant because we only stop the previous app's render loop, tear it down, and exec the new code in the same runtime.

How imgui_bundle supports this, in case it's a useful reference:

• Importing imgui_bundle under Pyodide automatically patches hello_imgui.run / immapp.run into a non-blocking renderer driven by requestAnimationFrame, with a setup / render / teardown lifecycle: pyodide_patch_runners.py
• Before exec'ing a new demo, the playground calls stop_active_renderer() from that module, so the previous loop stops cleanly before its globals get rebound (the comments in that file describe the race this avoids)
• Playground source: https://github.com/pthom/imgui_bundle/tree/main/pyodide_projects/projects/playground (demo switching is in js/pyodide_loader.js)

Since fastplotlib drives its own loop via rendercanvas, this is not drop-in for you. But the same pattern may apply: keep one runtime alive, add a "stop the current loop and tear down" hook on the rendercanvas side, then run the next example against the same runtime and canvas.

Second suggestion: embrace the async model end to end. Two things mattered when I adapted imgui_bundle's runners to the browser:

• Never block or sleep in Python while a GUI is up. Each requestAnimationFrame callback renders exactly one frame and returns; anything that needs waiting (downloads, etc.) is a real await outside the frame callback.
• In the browser, run() becomes fire-and-forget: it sets up the app, schedules the first requestAnimationFrame callback, and returns immediately. The GUI then lives entirely in browser callbacks, so the rest of the script (and other asyncio tasks) keeps running between frames. I also provide an awaitable run_async() for code that needs to know when the GUI exits.

A nice side effect of this fully callback-driven approach: it never needs run_sync, and therefore does not depend on JSPI ("WebAssembly stack switching", the experimental feature that lets run_sync suspend synchronous code while a promise resolves; currently Chrome-only). That is why the playground also works on Firefox, and it matches your hunch that moving fully async would remove the JSPI requirement.

For what it's worth, when I tried this PR on Firefox, the first failure I hit was the font loading in pygfx: run_sync(face.load().then(...)) in pygfx/utils/text/_fontfinder.py. It would be an interesting candidate to convert to a plain await.

One last trick: a synchronous download is still possible without JSPI, because the legacy synchronous XMLHttpRequest blocks inside the browser itself, not in the WASM stack. imgui_bundle uses this in immapp.download_url_bytes (binary data needs a small base64 detour, see the code; the tab is frozen while downloading, so it's for one-shot loading, not mid-frame use). It could be a Firefox-compatible replacement for (note that it only works for downloads though).

Finally, there are more recent wheels for imgui bundle here : https://imgui-bundle.pages.dev/local_wheels/
(they are lighter: 5MB instead of 9MB). I hope to deploy those will be available in the standard pyodide distrib soon.

Happy to discuss details here or on discord.

hey @pthom thanks for you advice. I can see the benefit in all of and really think the playground kinda approach would work out.

We can gladly chat more on Discord as I have some additional ideas. I'd say that this PR is way ahead of the current blockers which are still in wgpu-py. Pygfx and fastplotlib should just work once that is ready and released.

How interactive docs/gallery might look and work is more of a design decision not really up to me.