Re:Pygfx
by blt on Friday October 25, 2024 @03:27PM
(#41948742)
this looks similar to VisPy (https://vispy.org/), are there any major differences?
[ Parent
| on HN ]
Re:Pygfx
by cipherself on Friday October 25, 2024 @04:01PM
(#41949090)
Pygfx uses webgpu while VisPy uses OpenGL.
Re:Pygfx
by almarklein on Saturday October 26, 2024 @08:40AM
(#41954397)
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.
From the same developer ;)
Re:Pygfx
by nighthawk454 on Saturday October 26, 2024 @12:08AM
(#41952472)
Oh thanks, I didn’t realize that. Having recently evaluated Vispy that really helps me place what this tool might be for
Re:Pygfx
by mardifoufs on Friday October 25, 2024 @07:23PM
(#41950946)
From my experience with vispy, it is more limited than pygfx. I mean, you can always use gloo to get whatever you want but the "built ins" are much more limited than what pygfx seems to have. I really like vispy anyways, I think this seems like an evolution with some lessons learnt from vispy.
Seems this needs a newish graphics driver stack to work.
Re:Pygfx
by almarklein on Saturday October 26, 2024 @09:04AM
(#41954495)
Apart from being based on wgpu, Pygfx also has a better design IMO. Korijn deserves the credit for this. It's inspired by ThreeJS, based on the idea to keep things modular.
We deliberately don't try to create an API that allows you to write visualizations with as few lines as possible. We focus on a flexible generic API instead, even if it's sometimes a bit verbose.
We leave it up to others to create higher level (domain specific) APIs. Fastplotlib is one example: https://github.com/fastplotlib/fastplotlib