[HN Gopher] Pygfx
___________________________________________________________________
Pygfx
Author : figomore
Score : 243 points
Date : 2024-10-22 22:10 UTC (4 days ago)
(HTM) web link (docs.pygfx.org)
(TXT) w3m dump (docs.pygfx.org)
| MiliasGeiger wrote:
| I used to love making physics visualizations using VPython[1]!
| It's awesome to see similar tools pop up. I gave up on VPython
| after python3, since it was a pain to migrate.
|
| [1]: https://vpython.org/
| prideout wrote:
| Am I the only one who is irked by by ads on Read the Docs pages?
| BiteCode_dev wrote:
| Yes, because all the other people on HN use unlock origin.
| stavros wrote:
| The what?
| littlestripes wrote:
| There are ads in docs now?? Thank my lucky adblocks
| anileated wrote:
| Let's put it this way: I would consider myself _eligible_ to be
| irked by ads on Read the Docs pages if I paid whoever maintains
| the project.
|
| If they bother you enough, absolutely no one's going to frown
| if you estimate how much they would be making on ads from
| traffic volume yearly, email the maintainer and suggest to pay
| that in return for turning off the ads for a year.
|
| ( _Some people_ might frown if you just block the ads, since
| after all it is robbing a fellow open-source dev of some
| income.)
|
| There are two points I am curious about:
|
| -- I would like to know if RTD forces the ads. Considering they
| have a business tier, it would be funny if they had to finance
| OSS project hosting from ads.
|
| -- EthicalAds started as an ad platform for developers, but
| apparently is now an "AI ad network". I wonder if Python OSS
| project owners know about the 180 degree turn that's happening
| there...
| almarklein wrote:
| 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 :)
| craigds wrote:
| We used the free tier for a couple of years before a user
| mentioned the ads. We had no idea our docs were surrounded by
| ads as no one on the team had ever tried it without ublock
| origin... We upgraded to the paid plan after that :)
| blt wrote:
| this looks similar to VisPy (https://vispy.org/), are there any
| major differences?
| cipherself wrote:
| Pygfx uses webgpu while VisPy uses OpenGL.
| almarklein wrote:
| 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.
| hmaarrfk wrote:
| From the same developer ;)
| nighthawk454 wrote:
| Oh thanks, I didn't realize that. Having recently evaluated
| Vispy that really helps me place what this tool might be for
| mardifoufs wrote:
| 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.
| fulafel wrote:
| Seems this needs a newish graphics driver stack to work.
| almarklein wrote:
| 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
| sevensor wrote:
| Suppose I want to wrap a GUI around my visualization. Can I hand
| pygfx a surface I created with a GUI tool kit?
| figomore wrote:
| It's possible to use Pygfx with Qt and WX.
| sevensor wrote:
| Nice! That's what I was hoping to hear!
| westurner wrote:
| pygfx/pygfx: https://github.com/pygfx/pygfx :
|
| > _Pygfx (pronounced "py-graphics") is built on wgpu, enabling
| superior performance and reliability compared to OpenGL-based
| solutions._
|
| pygfx/wgpu-py: https://github.com/pygfx/wgpu-py/ :
|
| > _A Python implementation of WebGPU_
|
| gfx-rs/wgpu: https://github.com/gfx-rs/wgpu :
|
| > _wgpu is a cross-platform, safe, pure-rust graphics API. It
| runs natively on Vulkan, Metal, D3D12, and OpenGL; and on top of
| WebGL2 and WebGPU on wasm._
|
| > _The API is based on the WebGPU standard. It serves as the core
| of the WebGPU integration in Firefox and Deno_
| the__alchemist wrote:
| I was/am a bit confused: I think this is unrelated to the wgpu
| cross-API toolkit in rust, it just abbreviated WebGpu the same
| way?
| samtheprogram wrote:
| 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
| westurner wrote:
| 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
| revskill wrote:
| Readthedocs is such the gold standard of a library documentation,
| it contains the complete guide to master the concepts, besides
| the API.
|
| Other languages, take a look and follow this standard, please.
| an1sotropy wrote:
| Suppose I'm using PySide6 and starting to use QRhi[1]. Is there a
| way to compare the portability and speed of pygfx (as within
| PySide6) with QRhi?
|
| [1]
| https://doc.qt.io/qtforpython-6/PySide6/QtWidgets/QRhiWidget...
| almarklein wrote:
| From what I understand, QRhi has a very different purpose then
| Pygfx, so I'm not sure how to answer this question.
| an1sotropy wrote:
| 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/QRhiWid
| get...
|
| [3] https://github.com/pygfx/wgpu-py/
|
| [4] https://github.com/gfx-rs/wgpu
| Calavar wrote:
| > How should I make an informed comparison between them?
|
| Pygfx provides higher level rendering primitives. The more
| apples to apples comparison would be wgpu-py versus QtRhi,
| both of which are middleware that abstract the underlying
| graphics API.
|
| The natural question is are you already using Qt? You say
| you are, so IMHO the pros and cons of the specific
| implementations don't matter unless you have some very
| specific exotic requirements. Stick with the solution that
| "just works" in the existing ecosystem and you can jump
| into implementing your specific business logic right away.
| The other option is getting lost in the weeds writing glue
| code to blit a wgpu-py render surface into your Qt GUI and
| debugging that code across multiple different render
| backends.
| almarklein wrote:
| Yeah, sounds like QRhi is about at the level of
| WebGPU/wgpu-py.
|
| It sounds to me that Qt created their own abstraction over
| Vulkan and co, because wgpu did not exist yet.
|
| I can't really compare them from a technical pov, because
| I'd have to read more into QRhi. But QRhi is obviously
| tight to / geared towards Qt, which has advantages, as well
| as disadvantages.
|
| Wgpu is more geared towards the web, so it likely has more
| attention to e.g. safety. WebGPU is also based on a
| specification, there is a spec for the JS API as well as a
| spec for webgpu.h. There's actually two implementations
| (that I know of) that implement webgpu.h: wgpu-native
| (which runs WebGPU in firefox) and Dawn (which runs WebGPU
| in Chrome).
| jcelerier wrote:
| 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 :'(
| CoastalCoder wrote:
| > Pygfx (pronounced "py-graphics")
|
| _Major_ tangent, but am I the only one who bristles at someone
| telling me how to pronounce an abbreviation they invented?
|
| I must have encountered this a few times in brand marketing
| within the tech world and gotten pissed off at feeling
| manipulated.
| gjm11 wrote:
| You aren't.
|
| I feel inclined (especially _because_ they 're trying to tell
| me otherwise) to pronounce it in a rather different way which I
| shall not make explicit here beyond saying that it splits as
| pyg/fx rather than as py/gfx.
| esperent wrote:
| I can't say you're the only one, but I've certainly never
| bristled over this before. Or even spared it any thought. And
| now that I am thinking about it, I find it quite helpful
| actually, not bristle-worthy at all. I still have no idea how
| to pronounce GIF or several other acronyms that I commonly use.
| ffsm8 wrote:
| You're angry because the author tried to make the library
| searchable by removing a few letters..?
|
| And they didn't even come up with the gfx shorthand for
| graphics, its admittedly an old one and barely seen nowadays...
| But it's always been the sister to sfx/sound effects
| swiftcoder wrote:
| It's also likely a reference to the rust library underlying
| this whole stack (gfx-rs)
| webmaven wrote:
| 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.
| ..
| nighthawk454 wrote:
| I mean that seems a bit uncharitable. I don't think the author
| communicating their intent behind the name is aggravating or
| manipulative. It's simply an explanation. Shouldn't be worth
| more than an 'ah, I see what they're going for' and move on.
|
| It's a sign, not a cop. Doesn't seem like any undue pressure to
| control people, or prevent the reader from doing what they will
| with.
|
| One wonders if the IPA pronunciations on Wikipedia is similarly
| bristling
| anileated wrote:
| Whether you are a user bristling at a library author telling
| you how to pronounce the name of the project, or library author
| bristling at people mispronouncing the name of the project, in
| OSS world we all have our things to bristle about but differ in
| our abilities to influence them.
| swiftcoder wrote:
| I think that it is pretty important to both be prescriptive
| about the pronunciation of abbreviations you create, and to
| explain them if they are non-obvious.
|
| Way back when I first read about nginx, I had absolutely no way
| to know that folks usually pronounced it "engine-X". Led to an
| embarrassing conversation where I and a coworker were
| completely at cross-purposes to one another.
|
| Obviously there are a bunch of abbreviations with disputed
| pronunciations (gif/jif, SQL/sequel, etc), and since the
| creators weren't prescriptive about them, we're all free to
| argue about them for the rest of time...
| wruza wrote:
| Important embarrassing why? In my experience it's only really
| important to insufferable people who care about their in-
| groupness before anything else.
| exe34 wrote:
| do you have the same reaction to people telling you how to
| pronounce their names or others telling you what pronouns to
| use?
| indulona wrote:
| pigfix
| fulafel wrote:
| As this is using wgpu, it will be interesting if in the future
| they get it to run in the browser (Python already does, with
| Pyodide).
|
| There are some tickets about it:
| https://github.com/pygfx/pygfx/issues/650
| https://github.com/pygfx/wgpu-py/issues/407
| almarklein wrote:
| It's definitely still our intention to make it run in the
| browser. We're not actively working on that yet, but we've
| recently been able to remove some hurdles on that path, in
| particular the issue related to Webgpu being async.
| nmstoker wrote:
| 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!
| raytopia wrote:
| If someone is looking for a renderer that also has tools for game
| development in Python. Panda3D is another good choice. It has a
| task and event system along with multiplayer and physics.
| actinium226 wrote:
| Very cool, I wonder how this compares to Panda3D?
| federicotdn wrote:
| Question slightly related to this topic: how do native (e.g. Qt,
| GTK, etc.) desktop applications usually embed 3D views? Say for
| example, a desktop application for visualizing .obj files. Or
| something like AutoCAD, maybe (though I'm not sure which UI
| framework it uses).
| almarklein wrote:
| Not sure if this is what you're asking :) but the UI framework
| will somehow provide access to the OS-level surface object, so
| that the GPU API can render directly to the screen.
| federicotdn wrote:
| Makes sense!
___________________________________________________________________
(page generated 2024-10-26 23:04 UTC)