Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pygfx

docs.pygfx.org

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Pygfx

#41

Post by webmaven »

ffsm8 wrote: post #24
CoastalCoder wrote: post #21

> 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.

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

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...

Re: Pygfx

#42

Post by an1sotropy »

almarklein wrote: post #37
an1sotropy wrote: post #20

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...

From what I understand, QRhi has a very different purpose then Pygfx, so I'm not sure how to answer this question.

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

Re: Pygfx

#43

Post by exe34 »

CoastalCoder wrote: post #21

> 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.

do you have the same reaction to people telling you how to pronounce their names or others telling you what pronouns to use?

Re: Pygfx

#44

Post by nmstoker »

almarklein wrote: post #35
fulafel wrote: post #31

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

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.

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!

Re: Pygfx

#45

Post by Calavar »

an1sotropy wrote: post #42
almarklein wrote: post #37

Earlier quoted context omitted.

From what I understand, QRhi has a very different purpose then Pygfx, so I'm not sure how to answer this question.

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,…

> 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.

Re: Pygfx

#47

Post by jcelerier »

almarklein wrote: post #37
an1sotropy wrote: post #20

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...

From what I understand, QRhi has a very different purpose then Pygfx, so I'm not sure how to answer this question.

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 :'(

Re: Pygfx

#48

Post by wruza »

swiftcoder wrote: post #32
CoastalCoder wrote: post #21

> 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.

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 abbre…

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

Re: Pygfx

#49

Post by federicotdn »

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).

Re: Pygfx

#50

Post by almarklein »

an1sotropy wrote: post #42
almarklein wrote: post #37

Earlier quoted context omitted.

From what I understand, QRhi has a very different purpose then Pygfx, so I'm not sure how to answer this question.

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,…

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).

Post reply on HN