Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: move wgpu.gui into a new library #627

Open
almarklein opened this issue Oct 21, 2024 · 4 comments
Open

Proposal: move wgpu.gui into a new library #627

almarklein opened this issue Oct 21, 2024 · 4 comments

Comments

@almarklein
Copy link
Member

almarklein commented Oct 21, 2024

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
Copy link
Member Author

@almarklein
Copy link
Member Author

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 almarklein pinned this issue Oct 25, 2024
@almarklein
Copy link
Member Author

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

@almarklein
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant