wgpu-py icon indicating copy to clipboard operation
wgpu-py copied to clipboard

Proposal: move wgpu.gui into a new library

Open almarklein opened this issue 1 year ago • 4 comments

TL;DR

  • We're moving wgpu.gui into a new library called rendercanvas: https://github.com/pygfx/rendercanvas
  • The wgpu.gui will remain working for a while, to ease transition.
    • This means updates to wgpu can be applied, and new releases be made, without interfering with this transition.
  • We'll create documentation on how to update to rendercanvas.
  • When we get to the "update propagation" work in Pygfx, Pygfx will switch to rendercanvas.
  • The wgpu.gui will be deprecated sometime after the "update propagation" changes in pygfx are all done. Nu rush.

In earlier work the API for the canvas was separated better from wgpu itself. The idea was that in principal it should be considered a separate package. I now think we should really make it a separate package.

In short, the reason is that the canvas logic and API are about orthogonal to wgpu. It also solves a completely different problem. Things like tests and docs are also very different. Also, wgpu can be used without a canvas, and a canvas can potentially also be used without wgpu (it already supports displaying bitmap images).

With the rework that's on the way in #618 (and follow-up prs), I think now would be a really good time. We can apply all the new stuff (which will change the API a bit) to the new library, while we keep wgpu.gui as-is until we gradually deprecate it.

The purpose of the new lib would be the same as our current wgpu.gui, but let's make it explicit:

  • Providing a generic canvas API to render to (with wgpu).
  • Providing canvas implementations for various GUI libraries (e.g. qt and wx) and platform (e.g. Jupyter, browser).
  • Providing an event system with standardized event objects.
  • Providing an event loop and scheduling.

almarklein avatar Oct 21 '24 08:10 almarklein

https://github.com/pygfx/rendercanvas

almarklein avatar Oct 24 '24 14:10 almarklein

My proposal is:

from rendercanvas.auto import RenderCanvas

That name is free and pretty clear: it's a canvas to render to. Not wgpu-specific, actually, since anything that can render using either a window-id, or by providing an image, can use it.

If you feel like bike-shedding on the name, I'm up for it 😄


I want to use the same select-by-import mechanics as before, and extend it a little bit:

# Auto-select
from rendercanvas.auto import RenderCanvas

# Explicit lib
from rendercanvas.glfw import RenderCanvas

# Qt needs to know what lib to use
import PySide6
from rendercanvas.qt import RenderCanvas

# Let's also make this work
from rendercanvas.pyside6 import RenderCanvas 

# If you have a renderer that only produces images
from rendercanvas.auto_image import RenderCanvas

almarklein avatar Oct 25 '24 08:10 almarklein

I added a quick summary in the top post to what this change means for downstream libraries. In short: no rush yet.

almarklein avatar Oct 25 '24 08:10 almarklein

I moved multiple issues, that related to the canvas, from wgpupy to the rendercanvas repo.

almarklein avatar Nov 22 '24 15:11 almarklein

This is done. There is still a stub in wgpu.gui that just loads from rendercanvas, but its not documented, and we'll remove that in a a few months/releases.

almarklein avatar Sep 16 '25 09:09 almarklein