Zed editor switching graphics lib from blade to wgpu

Post by pjmlp » Fri, Feb 13, 2026, 3:39 PM UTC

flohofwoe wrote: post #22

swiftcoder wrote: post #17

Earlier quoted context omitted.

> they felt their native renderer on those platforms was better and less memory intensive This definitely would be worth some profiling. I don't think it's a given that their custom stacks are going to beat wgpu in a meaningful way.

WebGPU has some surprising performance problems (although I only checked Google's Dawn library, not Rust's wgpu), and the amount of code that's pulled into the project is massive. A well-made Metal renderer which only implements the needed features will easily be 100x smaller (in terms of linecount) and most likely faster.

Post by pjmlp » Fri, Feb 13, 2026, 3:41 PM UTC

swiftcoder wrote: post #15

conorbergin wrote: post #11

Is webgpu a good standard at this point? I am learning vulkan atm and 1.3 is significantly different to the previous APIs, and apparently webgpu is closer in behavior to 1.0. I am by no means an authority on the topic, I just see a lack of interest in targeting webgpu from people in game engines and scientific computing.

It's a good standard if you want a sort of lowest-common-denominator that is still about a decade newer than GLES 3 / WebGL 2. The scientific folks don't have all that much reason to upgrade from OpenGL (it still works, after all), and the games folks are often targeting even newer DX/Vulkan/Metal features that aren't supported by WebGPU yet (for example, hardware-accelerated raytracing)

Post by cess11 » Fri, Feb 13, 2026, 3:45 PM UTC

IshKebab wrote: post #45

paddy_m wrote: post #30

Earlier quoted context omitted.

I'd love to read a writeup of the state of Rust GUI and the ecosystem if you could point me at one.

https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-... I started writing a program that needed to have a table with 1 million rows. This means it needs to be virtualised. Pretty common in GUI libraries. The only Rust GUI library I found that could do this easily was gpui-component ( https://github.com/longbridge/gpui-component ). It also renders text crisply (rules out egui), looks nice with the default styl…

Post by atombender » Fri, Feb 13, 2026, 3:50 PM UTC

nu11ptr wrote: post #57

atombender wrote: post #38

Earlier quoted context omitted.

I tried gpui recently and I found it to be very, very immature. Turns out even things like input components aren't in gpui, so if you want to display a dialog box with some text fields, you have to write it from scratch, including cursor, selection, clipboard etc. — Zed has all of that, but it's in their own internal crates. Do you know how well gpui-component supports typical use cases like that? Edit boxes, buttons…

Yeah, running just gpui is kinda like writing a react app without a component library. It is going to be on you to implement all your components. All of those are handled. Run the "story" app. It is very impressive IMO. Components list: https://longbridge.github.io/gpui-component/docs/components/

Post by pjmlp » Fri, Feb 13, 2026, 3:52 PM UTC

PKop wrote: post #70

pjmlp wrote: post #21

Earlier quoted context omitted.

Interesting read, however as someone from the same age group as Casey Muratori, this does not make much sense. > The "immediate mode" GUI was conceived by Casey Muratori in a talk over 20 years ago. Maybe he might have made it known to people not old enough to have lived through the old days, however this is how we used to program GUIs in 8 and 16 bit home computers, and has always been a thing in game consoles.

> Maybe he might have made it known to people Yes, he coined the term rather than invent the technique