Pygfx (opens in new tab)

Great to hear that - I was impressed by pygfx but my immediate thought was that in this age of near universal browser access, it's a shame there's no ability to interact from there!

QRhi + Qt3D & / QtQuick3D is pretty much the exact same goal than pygfx with a different implementation: https://github.com/qt/qtbase/tree/dev/src/gui/rhi ; https://doc.qt.io/qt-6/qt3d-index.html ; https://doc.qt.io/qt-6/qtquick3d-index.html ; QRhi itself pretty much sits at the "wgpu" abstraction layer.

I've been using it for 4-ish years now in https://ossia.io (just the RHI part)

Pros:

- Integrates with Qt (of course).

- Really really easy API compared to the average C++ API.

- Works absolutely everywhere.

- Many provided examples: https://github.com/qt/qtbase/tree/dev/tests/manual/rhi

- Shader language is SPIRV-compatible GLSL 4.x thus it makes it fairly trivial to import existing GL shaders (one of my requirements was support for https://editor.isf.video shaders).

Cons:

- Was developed before Vulkan Dynamic Rendering was introduced so the whole API is centered around the messy renderpass thing which while powerful is sometimes a bit more tedious than necessary when your focus is desktop app development. However, Qt also has a huge focus on embedded so it makes sense to keep the API this way.

- Most likely there are some unnecessary buffer copies here and there compared to doing things raw.

- Does not abstract many texture formats. For instance still no support for YUV textures e.g. VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and friends :'(

Sorry, I'll try to be clearer. QRhi docs[1] say "The Qt Rendering Hardware Interface is an abstraction for hardware accelerated graphics APIs, such as, OpenGL, OpenGL ES, Direct3D, Metal, and Vulkan." And PySide6 includes a (python) wrapper for QRhi[2]. Meanwhile, pygfx builds on wgpu-py[3] which builds on wgpu[4] which is a "is a cross-platform, safe, pure-rust graphics API. It runs natively on Vulkan, Metal, D3D12, and OpenGL".

So, from the standpoint of someone using PySide6, QRhi and pygfx seem to be alternative paths to doing GPU-enabled rendering, on the exact same range of GPU APIs.

Thus my question: How do they compare? How should I make an informed comparison between them?

[1] https://doc.qt.io/qt-6/qrhi.html

[2] https://doc.qt.io/qtforpython-6/PySide6/QtWidgets/QRhiWidget...

[3] https://github.com/pygfx/wgpu-py/

[4] https://github.com/gfx-rs/wgpu

Per the `wgpu-py` README:

> Technically speaking, wgpu-py is a wrapper for wgpu-native, exposing its functionality with a Pythonic API closely resembling the WebGPU spec.

`wgpu-native` is a wrapper with FFI/bindings for the Rust `wgpu` per their READMEs

Same, I had assumed they weren't independent.

/?PyPI wgpu: https://pypi.org/search/?q=wgpu

Looks like xgpu is where it's actually at.

xgpu: https://github.com/pyrym/xgpu :

> xgpu is an aggressively typed, red-squiggle-free Python binding of wgpu-native, autogenerated from the upstream C headers

wgpu-py has a conda-forge package: https://anaconda.org/conda-forge/wgpu-py

This is indeed one of the major differences. Many of the problems that are plaguing Vispy are related to OpenGL. The use of wgpu solves many of them.

Also, wgpu forces you to prepare visualizations in pipeline objects, which at drawtime require just a few calls. In OpenGL there is way more work for each object being visualized at drawtime. This overhead is particularly bad on Python. So this particular advantage of wgpu is extra advantageous for Python.

Oh thanks, I didn’t realize that. Having recently evaluated Vispy that really helps me place what this tool might be for

Nice! That’s what I was hoping to hear!

Makes sense!

I wish. The revenue from the ads goes to readthedocs, AFAIK nothing is paid to the maintainers of the project.

That said, readthedocs is a pretty nice platform to host your docs in a simple way. Plus users are not tracked. So personally I don't mind so much, but I'm going to have a look at the paid plan to remove ads for our users :)

It's also likely a reference to the rust library underlying this whole stack (gfx-rs)

Alternatively, "Special Effects". Also VFX/Visual Effects, etc., one supposes.

Although that would have it expand to "Graph Effects" (hmm, that could be an interesting library), or "Graphic Effects".

But GFX expanding to simply "Graphics" has a history going back at least to the early 1990s, and even further:

https://books.google.com/books?id=Jy8EAAAAMBAJ&pg=PA35&dq=%2...

Important embarrassing why? In my experience it’s only really important to insufferable people who care about their in-groupness before anything else.