-
-
Notifications
You must be signed in to change notification settings - Fork 50
Description
We're seeing several reports where people have issues related to wgpu creating a surface. I created this as a meta-issue.
Issues in wgpu-py / rendercanvas / pygfx
- No config found pygfx#642
- thread panic when creating surface #663
- React to changing winId? rendercanvas#62
- [Qt] multiple window/docking support rendercanvas#55
- RuntimeError: Request adapter failed (1) pygfx#951
Known upstream issues
TODO
Improvements made
- Better canvas cleanup, avoids segfaults on some systems with glfw+wgpu rendercanvas#73
- Improve get_current_texture for window resizing #705
Specific cases
Linux
Make sure you've done
sudo apt install mesa-vulkan-drivers
sudo apt install xserver-xorg-core libvulkan1
WSL
wgpu does not really work on WSL yet, see gfx-rs/wgpu#1443. I think you can use a limited subset with the OpenGL backend.
Qt subwidgets
Qt does not like it when we claim a widget as a native widget, and this can cause some nasty side-effects. I think the best solution is a bitmap-present, maybe combined with an QGLWidget.
Wayland
The glfw GUI backend works via the x11 compat layer. But other backends don't work because the display id cannot be obtained. With the Qt backend it automatically fall back to bitmap on wayland.
Solutions
Using the bitmap mode
The simples approach (and one that we can control) is the present_method="bitmap"
in rendercanvas
. It does suffer a performance penalty, but we already know how we can reduce that penalty: pygfx/rendercanvas#66
Solutions to actually allow rendering to a surface
Wait 🤷 Except for the specific cases above, wgpu-core will likely improve on this front.
Maybe some tricks can be read in https://github.com/gfx-rs/wgpu/issues