almarklein

I don't know Datashader that well, but from what I understand, it generates an image from a set of primitives (e.g. points), and then allows you to interactively inspect that image. It does not re-render the points on every frame like Fastplotlib/Pygfx does.

Depending on your GPU, you can render say 1-50 million points smoothly. Also see e.g. https://github.com/pygfx/pygfx/discussions/819

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

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

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

Improved support for using the keyboard, including keyboard shortcuts.

This has been fixed now.

This has been fixed!

Good point. I guess I just defaulted to GPL. At first glance, I think it does not matter since Aferro protects code that runs serverside, and the TimeTagger library is both server and client side code. Edit: but it would not hurt to consider this better...

Thanks, good point!

Thanks for the clarification! I see what you mean now. 1. I think I'd go with graying-out records that do not match the selected tags. 2. The tags are part of the description, but indeed this is hard to process further. We should add a column for just the tags.

Thanks for the feedback! Your suggestion about tag colors is interesting - my earlier timetracker (timeturtle.app) does exactly this, but I felt the colors were too distracting. Will think about how to bring back some of the info in the overviews. Perhaps by simply showing tags in a subtle color.

Thanks for the constructive feedback!

Will check it out, and am looking forward to your writeup!

I figured I'd want to make it cheaper than Toggl et al., because people might feel they'd get less features. Plus there is no free plan, so the paid plans don't have to pay for the free users ;) - Anyway, I'm kinda done with multiple tiers, and like the idea of one simple price.

Thanks, I'm glad someone actually takes notice. I really care about this, and would love more people to do too :)

Thanks for the feedback! The blocks on the left (in the timeline) represent the individual time records. These are indeed "glued together" when a new record starts right after another stops. You can only drag a record in the timeline when it's first selected, so it should be impossible to affect multiple at once. You can also move and zoom the timeline though, perhaps this is what was happening?

Sounds like a cool project, but I think I'll focus on my Python scrips for now :)

That sounds cool!

Thanks for the great feedback, very valuable indeed! At the moment, deleting a record is not implemented yet, but it's somewhere near the top of the todo list :)