vello VS xilem

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.

The web browser gives us an extremely frictionless development and deployment process. Our CI generates a fully deploy at a unique link for every commit which lets us open and test PRs with a single click. It deploys updates to users without needing to make them go through an updater. In these relatively early stages of our development process, the importance of the velocity that gives us cannot be understated. Plus, the ability for users to try it out in one second is quite helpful.

I've designed the whole architecture specifically to avoid the web UI "feeling like a web app" with the subtle latency of interacting with the site. I wrote all-custom UI components using the minimal amount of HTML and CSS to achieve the requirements instead of depending on an external component framework which always loves nesting dozens of `div`s inside each other to achieve what should be doable in one or two. And our highly-lightweight JS which calls into Rust (Wasm) lets it keep the slow logic out of slow JS. And we are using Svelte to move most of the frontend DOM management logic from runtime to compile time. This architecture really helps us keep performance levels as close as possible to feeling native despite using the web for its GUI rendering; and I believe it has succeeded at feeling responsive by comparison to most other web apps you use (even Slack, for example, which shouldn't be nearly as complex).

Web lets us build fast, deploy the latest version to users fast, leverage prevalent developer experience with HTML/CSS for creating GUIs, and avoid getting stuck in a box with Rust's currently-immature GUI ecosystem. That's the tradeoff we had to make early on, and it was a good decision. But we will eventually move towards a fully native version...

In the short term, we plan to use [Tauri](https://tauri.app/) which is sort of a hybrid between Electron and a native application. It uses the OS's webview to shrink the shipped binary to only a few megabytes and reuse shared memory resources with other webviews at runtime. It also runs all our Rust code natively instead of through WebAssembly so all the business logic in Graphite runs natively and only the thin UI layer becomes dependent on web tech for the GUI display.

In the long term, we plan to rewrite the entire GUI in [Xilem](https://github.com/linebender/xilem) which is the up-and-coming Rust GUI that I believe will finally get everything right, including performance (which is something many desktop GUI frameworks are actually bad it, and sometimes even worse than web). We'll still deploy a web version but at that point, it will become native-first.

Hopefully that roadmap and explanation of the architectural decisions clears up any worries about the short and long term state of our GUI.

That said, Xilem is very close to that idea, but it's in its very early stages and nowhere near Flutter's capabilities.

xilem#62 demonstrates how Xilem's reactive layer can target DOM nodes.

Inspired by Xilem, Leptos and rui, Floem aims to be a high performance declarative UI library with minimal effort from the user.

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)

Yeah, Druid is being replaced by Xilem, but unfortunately Xilem isn't ready yet. So that whole project's in a bit of an awkward in-between phase where there isn't really any toolkit that can be recommended.

Third, we are discontinuing Druid proper. Years of experience has shown that people can struggle with the Druid data architecture and we can do better. This layer will be replaced by a new project called Xilem. We have spent a lot of time thinking about it and this decision was not taken lightly. You can read a more detailed post about the Xilem architecture but the gist of it is that we've found at a way to code UI in Rust that feels a lot more effortless than previous attempts. Xilem will look very intuitive to those familiar with state of the art toolkits such as SwiftUI, Flutter, and React, while at the same time being idiomatic Rust. Also we plan to port as many widgets from Druid to Xilem as possible, which should give the project a reasonable timeline to v0.1. Hopefully later this year.