vello VS druid

I'm looking forward to doing careful benchmarking, as this renderer absolutely looks like it will be competitive. It turns out that is really hard to do, if you want meaningful results.

My initial take is that performance will be pretty dependent on hardware, in particular support for pixel local storage[1]. From what I've seen so far, Apple Silicon is the sweet spot, as there is hardware support for binning and sorting to tiles, and then asking for fragment shader execution to be serialized within a tile works well. On other hardware, I expect the cost of serializing those invocations to be much higher.

One reason we haven't done deep benchmarking on the Vello side is that our performance story is far from done. We know one current issue is the use of device atomics for aggregating bounding boxes. We have a prototype implementation [2] that uses monoids for segmented reduction. Additionally, we plan to do f16 math (which should be a major win especially on mobile), as well as using subgroups for various prefix sum steps (subgroups are in the process of landing in WebGPU[3]).

Overall, I'm thrilled to see this released as open source, and that there's so much activity in fast GPU vector graphics rendering. I'd love to see a future in which CPU path rendering is seen as being behind the times, and this moves us closer to that future.

[1]: https://dawn.googlesource.com/dawn/+/refs/heads/main/docs/da...

[2]: https://github.com/linebender/vello/issues/259

[3]: https://github.com/gpuweb/gpuweb/issues/4306

Dioxus is working on this with blitz. It's leveraging wgpu through the linebender group's Vello renderer. Still in early stages.

If you're doing advanced compute work (including lock-free data structures), then it's best effort.

https://github.com/linebender/vello/issues/42 is an issue from when Vello (then piet-gpu) had a single-pass prefix sum algorithm. Looking back, I'm fairly confident that it's a shader translation issue and that it wouldn't work with MoltenVK either, but we stopped investigating when we moved to a more robustly portable approach.

There are a number of up-and-coming Rust-based frameworks in this niche:

- https://github.com/iced-rs/iced (probably the most usable today)

- https://github.com/vizia/vizia

- https://github.com/marc2332/freya

- https://github.com/linebender/xilem (currently very incomplete but exciting because it's from a team with a strong track record)

What is also exciting to me is that the Rust GUI ecosystem is in many cases building itself up with modular libraries. So while we have umpteen competing frameworks they are to a large degree all building and collaborating on the same foundations. For example, we have:

- https://github.com/rust-windowing/winit (cross-platform window creation)

- https://github.com/gfx-rs/wgpu (abstraction on top of vulkan/metal/dx12)

- https://github.com/linebender/vello (a canvas like imperative drawing API on top of wgpu)

- https://github.com/DioxusLabs/taffy (UI layout algorithms)

- https://github.com/pop-os/cosmic-text (text rendering and editing)

- https://github.com/AccessKit/accesskit (cross-platform accessibility APIs)

In many cases there a see https://blessed.rs/crates#section-graphics-subsection-gui for a more complete list of frameworks and foundational libraries)

blessed.rs lists these three crates for 2D drawing: - https://lib.rs/crates/femtovg - https://lib.rs/crates/skia-safe - https://github.com/linebender/vello

Vello (https://github.com/linebender/vello) which uses wgpu to render Edit: just saw you require images. Vello doesn't support those yet

How does this relate to Vello? Both target raw-window-handle for winit compatibility. Vello uses WGPU vs piet-glow using GL.

Finally, maybe vello could help you with ideas. It's not production ready yet, but they have some interesting ideas for 2D rendering using wgpu.

For GUI applications, the story is mixed. There are several GUI frameworks in active development, but nothing as polished and battle-tested as Electron for TypeScript. There are bindings to GTK, but they're cumbersome to work with, and I wouldn't recommend it to a Rust newbie. There's also Tauri, which is a bit like Electron and lets you write the GUI in HTML/CSS/JS and the business logic in Rust.

Concerning GUI frameworks, the most common ones are druid, egui and iced. All three of them run native and on the Web.

Going to give a shoutout to druid. I've recently tried it with the Lapce editor and it's just so smooth, fast and works so well for a pre-alpha app.

As iced and egui were difficult for me, i started with druid.

There is Iced which is used by system76 in Pop!_OS, Druid [DISCONTINUED], GTK-rs, Relm, Azul and Tauri. Personally I would use Tauri for its speed using the OS's native web render, documentation of use with things such as Sveltekit and the ability to make UI's using JS, CSS and HTML. Tauri similarly to Electron whilst being far faster. But its up to personal preference really. There aren't any solid "go to" options at the moment.

Druid should be good for most cases, it has a lot of built-in widget for the UI, you can even make a custom widget with a canvas-alike painting API.

Druid, which is a Rust-native UI toolkit for building desktop applications targeting Windows/macOS/Linux/OpenBSD/FreeBSD, has a new version out - v0.8.

There's a memoize View node in the previous iteration of the Xilem prototype, but it hasn't made it in to the current branch yet. That sounds like what you're asking, but it's possible I'm missing something.

You can use GTK from Rust. But the Rust native ones aren't really there yet. [Iced](https://github.com/iced-rs/iced) which has been picked up by System76 and [Druid](https://github.com/linebender/druid) (and it's next gen version [Xilem](https://github.com/linebender/xilem)) are the ones to watch, along with Dioxus which is the main post here.

I'd expect there to be something useable by the end of 2023.