almarklein

All true, except the bit that wgpu-py compiles to WASM. It's all desktop.

In the plans that we do have for running the browser, Fastplotlib, Pygfx and wgpy-py will still be Python, running on CPython that is compiled to WASM (via Pyodide). But instead of wgpu-py cffi-ing into a C library, it would make JS calls to the WebGPU API.

That's because WebGPU is still experimental. This will change, as it's set to replace WebGL.

Fastplotlib / pygfx are primarily meant to run on desktop. When using it via the notebook the server does the rendering.

As Ivo said, we have plans to support running in the browser via Pyodide, which opens some interesting things, but is not the primary purpose.

I have a feeling there's room for improvement for importing Pygfx as well. I think we should indeed strive that simple plots load super-quick.

To clarify this a bit, wgpu is a Rust implementation of WebGPU, just like Dawn is a C++ implementation of WebGPU (by Google). Both projects expose a C-api following webgpu.h. wgpu-py Should eventually be able to work with both. (Disclaimer: I'm the author of wgpu-py)

One big difference is that Fastplotlib is based on GPU tech, so its capable of rendering much larger datasets interactively.

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.

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

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

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

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.

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.

As a contractor I would never install spyware on my machine for a client. That's not a healthy professional relationship.

I do see the problem that some people pretend to be more experienced than they are, or worst case are scamming clients.

On the one hand, you could ask a contractor to do a certain (well-specified) piece of work for a fixed price. But it's often hard to define the specifications precisely, especially in software projects.

The alternative is charging by the hour. I see this as a journey that the client and contractor take together. You have a certain goal in mind, and the contractor helps you work towards it. You need regular meetings to discuss the progress, obstacles, and together decide on the best way forward. Daily standups could help too, but depending on the complexity of the work, I'd recommend a weekly or biweekly in-depth meeting.

Could it be that the experience with scammy contractors is because they are given a task towards an ill-defined goal with too little opportunity to discuss progress?

I'm generally eager to share what I make, and have written quite a few open source tools. It's gratifying to polish up a piece of software to a high standard ...

But deliberately not sharing your creation, keeping things idiosyncratic and a bit chaotic also has it's charm :) The bliss of knowing that you don't have to worry about code quality or users asking for new features!

I wrote some simple tools, e.g. a note-taking app, and scripts to organize photo's. I also wrote a time tracker :) but I open sourced that one (it's called timetagger).