9 ms·
Zed editor switching graphics lib from blade to wgpu
- andsoitis 8mo ago(for the linux renderer only)
- ZeroCool2u 8mo agoAn interesting side effect of moving to wgpu is that in theory with some additional work, this could allow you to run Zed in a web browser similarly to how some folks run VSCode as a remote interface to the backend running on a server.
- readitalready 8mo agoCan this be done on a cheap AWS EC2 instance?
- ZeroCool2u 8mo agoSure it takes very little hardware power to do this, but Zed isn't actually setup for this yet. This is in theory and after a few more API's are adapted.
- nu11ptr 8mo agoFrom the PR, it sounds like the switch to WGPU is only for linux. The team was reluctant to do the same for macOS/Windows since they felt their native renderer on those platforms was better and less memory intensive.
- ZeroCool2u 8mo agoYes, but they can add a flag to switch renderers on startup like they had for blade.
- swiftcoder 8mo ago> 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.
- flohofwoe 8mo agoWebGPU 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.
- pjmlp 8mo agoThere is also the issue that it is designed with JavaScript and browser sandbox in mind, thus the wrong abstraction level for native graphics middleware. I am still curious how much uptake WebGPU will end up having on Android, or if Java/Kotlin folks will keep targeting OpenGL ES.
- deleted 8mo ago[deleted]
- vitorsr 8mo agoPlease elaborate, I am curious to why would you think WebGPU would meaningfully beat their Metal/DirectX renderers.
- deleted 8mo ago[deleted]
- swiftcoder 8mo agoI don't think it would, but I don't think it's a given that their homegrown renderer is wildly more performant either - people tend to overestimate the performance of naive renderers
- arghwhat 8mo agoWell, not really. It means you have a renderer that is closer to being portable to web, not an editor that will run in web "with some additional work". The renderer was already modular before this PR.
- nindalf 8mo agoQuoting maddythewisp from that PR: > There is significant work beyond the renderer that would need to happen to run Zed in a browser - notably background tasks and filesystem/input APIs would need web/wasm-compatible implementations.
- rafaelmn 8mo agoRendering in the browser has nothing to do with being able to do remote editing like you can in VSCode - you would just be able to edit files accessible to the browser. Just like you can hook up local VS code native up to a random server via SSH, browser rendering is just a convenience for client distribution. You would need a full client/server editor architecture that VS code has.
- deleted 8mo ago[deleted]
- nahuel0x 8mo agoZed already has a client/server editor architecture: https://zed.dev/docs/remote-development https://zed.dev/docs/remote-development
- usefulcat 8mo agoIf you're talking about remote editing (editing files which reside on a remote server), Zed already supports that?
- Octoth0rpe 8mo agoI believe they're referring to running Zed entirely in a browser. This opens up possibilities like using zed for something like codepen, or embedding it into a git web frontend like gitea. Many projects like this basically embed vscode, a rare benefit of being an electron app which Zed is not.
- ZeroCool2u 8mo agoExactly.
- ethmarks 8mo agoA web port is apparently already on their roadmap: https://zed.dev/roadmap#:~:text=Zed%20on%20the%20Web https://zed.dev/roadmap#:~:text=Zed%20on%20the%20Web
- ZeroCool2u 8mo agoI didn't realize that, super exciting!
- piker 8mo agoRust GUI is in a tough spot right now with critical dependencies under-staffed and lots of projects half implemented. I think the advent of LLMs has been timed perfectly to set the ecosystem back for a few more years. I wrote about it, and how it affected our development yesterday: https://tritium.legal/blog/desktop https://tritium.legal/blog/desktop
- nu11ptr 8mo agoReally? It seems better than ever to me now that we have gpui-component. That seems to finally open doors to have fully native guis that are polished enough for even commercial release. I haven't seen anything else that I would put in that category, but one choice is a start.
- piker 8mo agoThe problem is that Zed has understandably and transparently abandoned supporting GPUI as an open source endeavour except to the extent contributions align with its business mission.
- nu11ptr 8mo agoI remember when that came out, but I'm not sure I understand the concern. They use GPUI, so therefore they MUST keep it working and supportable, even if updating it isn't their current priority. Or are you saying they have a closed source fork now? Actually, this story is literally them changing their renderer on linux, so they are maintaining it. > except to the extent contributions align with its business mission Isn't that every single open source project that is tied to a commercial entity?
- piker 8mo agoI don't know what the message means exactly, but I can't plan to build on GPUI with it out there, especially when crates that don't carry that caveat are suffering from being under-resourced.
- throwup238 8mo agoOh sweet! I threw out GPUI completely from one of my projects because of Blade. I needed headless with rendering to image for e2e testing and gave up on GPUI after trying to mess with Blade. It’s definitely a mess and moving to egui has only shuffled the deck chairs around.
- skerit 8mo agoWhy was Blade ever decided upon? Is it older than wgpu?
- conorbergin 8mo agoIs 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.
- swiftcoder 8mo agoIt'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)
- pjmlp 8mo agoKhronos is trying to entice scientific folks with ANARI, because there was zero interest to move from OpenGL as you mention. https://www.khronos.org/anari/ https://www.khronos.org/anari/
- flohofwoe 8mo agoFor a text editor it's definitely good enough if not extreme overkill. Other then that the one big downside of WebGPU is the rigid binding model via baked BindGroup objects. This is both inflexible and slow when any sort of 'dynamism' is needed because you end up creating and destroying BindGroup objects in the hot path. Vulkan's binding model will really only be fixed properly with the very new VK_EXT_descriptor_heap extension (https://docs.vulkan.org/features/latest/features/proposals/VK_EXT_descriptor_heap.html https://docs.vulkan.org/features/latest/features/proposals/V...).
- xyzsparetimexyz 8mo agoThe modern Vulkan binding model is relatively fine. Your entire program has a single descriptor set containing an array of images that you reference by index. Buffers are never bound and instead referenced by device address.
- Muromec 8mo agoOh, this is nice. Latest builds stopped working on panfrost because it does not announce the sufrace capabilities or something like that. Maybe I can have it back to working on the orange pi
- g947o 8mo agoWill this help running Zed in environments with no GPU/old GPUs? There have been some complaints about not being able to run Zed on Ivy Bridge or in VMs, even though browsers and other applications work perfectly fine
- alphazard 8mo agoCan someone, who knows computer graphics, explain why the old library had so many issues with flickering and black triangles or rectangles flashing on the app, and why the new library is expected to not have those same problems?
- StilesCrisis 8mo agoThe old graphics library was basically unmaintained; bug fix PRs were being ignored. WGPU is very actively maintained.
- flohofwoe 8mo agoSeeing that the author of Blade (kvark) isn't exactly a 3D API newbie and also worked on WebGPU I really wonder if a switch to wgpu will actually have the desired long term effect. A WebGPU implementation isn't exactly slim either, especially when all is needed is just a very small 3D API wrapper specialized for text rendering.
- littlestymaar 8mo agoKvark was leading the engineering effort for wgpu while he was at Mozilla. But he was doing that on his work time and did so collaborating with other Mozilla engineers, whereas AFAIK blade has been more of a personal side project.
- xyzsparetimexyz 8mo agoCross API graphics abstractions are almost always a bad idea even if its just wrapping modern DX12 and Vulkan, and always always are when Metal comes into the mix.
- athrowaway3z 8mo agoA bit of a tangent, but I wish the makepad project would get more traction in rust. Their cross-platform approach is extremely ambitious.
- fishgoesblub 8mo agoI hope this can somehow improve the font situation. Even on a 1440p monitor, the fonts in Zed are much blurrier than any other editor I've used. I Can't even use bitmap fonts like VSCode.
- TingPing 8mo agoFrom what I see wgpu isn’t using the same font stack as chromium. I think the Rust community would be against those dependencies. You can just convert bitmap fonts, supporting them doesn’t make sense in 2026.
- fishgoesblub 8mo agobitmap fonts are the only fonts where I can get crisp, sharp, and not blurry text. I don't have an expensive "Retina" style display.
- bschwindHN 8mo agowgpu is an API for rendering stuff on the GPU, it has no concept of font stacks or text rendering.
- TingPing 7mo agoI was talking about glyphon, wgpu-text, etc.
- TiredOfLife 8mo agohttps://zed.dev/releases/stable#:~:text=Improved%20editor%20font%20rendering%20on%20lodpi%20displays.%20(%2340401) https://zed.dev/releases/stable#:~:text=Improved%20editor%20... Fixed last october
- fishgoesblub 8mo agoTried it when it when that update released and just now, still blurry as ever.
- satvikpendem 8mo agoZed also stopped GPUI (their GPU accelerated Rust UI framework) development for now, sadly. > Hey y'all, GPUI develoment is getting some major brakes put on it. We gotta focus on some business relevant work in 2026, and so I'm going to be pushing off anything that isn't directly related to Zed's use case from now on. However, Nate, former employee #1 at Zed, has started a little side repo that people can keep iterating on if they're interested: https://github.com/gpui-ce/gpui-ce https://github.com/gpui-ce/gpui-ce. I'm also a maintainer on that one, and would like to try to help maintain it off of work hours. But I'm not sure how much I'll be able to commit to this https://discord.com/channels/869392257814519848/1440440628646514759/1449104973626347741 https://discord.com/channels/869392257814519848/144044062864...
- nu11ptr 8mo agoWhile unfortunate, to me this just says any user requested features aren't going to get merged anytime soon. As is, it already runs on windows/linux/mac, and will need to do so maturely for Zed to function. Therefore, to me, this isn't that big of a deal, and when they need things like web support (on their roadmap), they will then add that. I'm curious... does anyone have any PRs or features that they feel need merging in order to use GPUI in their own projects? (other than web support)
- satvikpendem 8mo agoI recently saw a PR where the author implemented shaders but it was closed by the maintainers as the feature wasn't needed by Zed the editor.
- nu11ptr 8mo agoThanks. I probably could have answered my own question had I simply looked here: https://github.com/gpui-ce/gpui-ce/pulls https://github.com/gpui-ce/gpui-ce/pulls and here: https://github.com/zed-industries/zed/pulls?q=is%3Apr+is%3Aopen+gpui https://github.com/zed-industries/zed/pulls?q=is%3Apr+is%3Ao...
- amelius 8mo agoWill this make Zed slower, since Wgpu is just a compatibility layer, adding more code?
- tracker1 8mo agoDepends on all implementation, environment and hardware details.
- badhorseman 8mo agoThe Zed editor seems kind of silly to me. I would rather my editor works in many possible environments maybe even one that only has a tty interface. What advantages are people finding with this editor other then high fidelity scrolling.
- linolevan 8mo agoEarly Zed user here. There’s a lot of small things you’ll hit if you use Zed where it’s a subtlety nicer design point, but one of the big ones for me is project-wide search. Zed’s multibuffers are SO much better than VS Code’s equivalent. If I’m debugging something on a coworkers laptop, VSCode is mostly usable until I hit that. If you’re a craftsman, it’s worth trying different tools!
- steve_adams_86 8mo agoAgreed, multibuffers are such a huge QOL feature. I love being able to work across a dozen or more buffers at once with no impact on performance. You can work in so many places at once, navigate from the buffer to its file and back, widen the buffer up or down, etc. It feels like a super power.
- chiffaa 8mo agoA lot of people use VSCode. Zed's value proposition is being basically that but with fully native code, so without the madness that is Electron. If you're not a fan of this kind of tooling, it's totally fine, but many people see the value in having an extensible graphical code editor
- badhorseman 8mo agoMy tone probably came off as antagonistic and that was not my intention. I was interested in if anyone was using the high fidelity graphical features for something other then making the environment prettier. I am always interested in what features new editors and how people use them and such and if I am missing out.
- the__alchemist 8mo agoI am confused by this without context. I have not heard of blade, but am aware that Zed built its own GUI library called GPUI. Having used Zed, this is a vote of confidence: The crate ecosystem is historically filled with libaries which try to be The future of X in rust but are disconnected from practical applications. GPUI by nature is not that; it's a UI lib built to a practical and non-trivial purpose. It sounds like Blade is a cross-API graphics engine, by one of the original gfx-HAL (former QGPU name) creators? I have not used GPUI beyond a simple test case, but had (prior to this news?) considered it for future projects. I am proficient with, and love EGUI and WGPU. (The latter for 3D). I have written a library (`graphics` crate) which integrates the two, and I use for my own scientific applications which have both 2D and 3D applications. Overall, I'm confused by this, as I was looking forward to using GPUI in future applications and comparing it to EGUI. I have asked online in several places for someone to compare who's used both, but I believe this to be a small pool. I was not sure of the integration between GPUI and WGPU, which can confirm EGUI and WGPU have great integration. But I only care about this because I do 3D stuff; if I were not, I would be using eframe instead of WGPU as the backend. Unrelated, off-topic, but I'm also not sure where to ask this: Am I missing something about Zed? I have tried and failed to get into it. I really want to like it because it's so fast [responsive], but it seems to lack basic IDE functionality in Python and Rust, like moving structs/functions, catching errors dynamically, introspection and refactoring in general etc. I thought I might be missing some config, but now lean that it's more of a project-oriented text editor than true IDE in the fashion of JetBrains. But I have been unable to get a confirmation, and people discuss it as if it's an IDE or JB alternative.
- gigatexal 8mo agoI am one plugin away from moving to it directly instead of vscode. I really like it. It’s fast. It gets updates seemingly daily. I’ve never had it crash. It integrates LLMs well. It’s everything I wish vscode was if it were native.
- the__alchemist 8mo agoI appreciate the info! Are you able to talk me through how to move a struct[class]?
- nmilo 8mo agoI find it odd the rust community feels the need to reimplement tried and tested APIs in "pure safe Rust". Like no other language has better C integration, and we have had cross-platform windowing libraries since like the 90's, why does everyone reach for a brand new unstable libraries with less maintainer support? Edit: replying to https://tritium.legal/blog/desktop https://tritium.legal/blog/desktop, not the OP
- jauntywundrkind 8mo agoAside from Rust being better (impl is such a great decoupling, fearless type safety), there is afaik nothing one tenth as useful and good as cargo & is crate ecosystem (docs rs, crates.io, and all the packages). I find it odd the broader hacker community feels the need to requestion and cross-examine every choice for using rust. Like, no other language has such great just works ergonomics, with a solid language, fantastic tooling, excellent packages that gives it a just works the first time cross-platform joy. Why does every thread have to spawn a brand new unsupported whinge throwing dirt at what seems like such an obvious enjoyable choice?
- shdh 8mo agoRust build times are not an enjoyable part of its DX
- nmilo 8mo agoAh, I meant to reply to https://news.ycombinator.com/item?id=47003058 https://news.ycombinator.com/item?id=47003058. Never questioned the use of Rust, only the need for the entire windowing stack to be in Rust (that blog post shows a case where it bit them)
- saghm 8mo agoI think you might be misunderstanding the parent comment. It sounds to me like they're arguing in favor of wrapping C GUI library when writing a GUI app in Rust, not avoiding Rust entirely. As far as I can tell, they're arguing for writing new stuff in Rust that happens to be re-using some components that aren't in Rust. I'd argue that's entirely in the spirit of Rust; kind of the whole point is that you can put a hard boundary on where the unsafety lies and make everything safe outside of that boundary. When I use a Vec or a HashMap, there's unsafe code under the hood, but it doesn't stop me from writing my own code without needing to dip into unsafe at all, and there's no fundamental reason why the same couldn't be done by wrapping Qt or Gtk on Linux or Cocoa or MacOS.
- 29athrowaway 8mo agowgpu's OpenGL support is kind of broken. wgpu + Vulkan is the stable combination, unless I am mistaken
- KingOfCoders 8mo agoSwitched from Intellij (various) to Cursor because of AI integration, only using Claude Code CLI, switched to VS because Cursor became so annoying every release, pushing their agents down my throat, activating what I did deactivate every release, recently thought "Why do I even use that slow bloated thing of VS?" and switched to Zed. Very happy camper. So much faster. So much snappier. Would love Claude Code CLI integration but can live without it. Would pay for Zed as I did pay ~25y for Intellij.
- clickety_clack 8mo agoYep. Zed is the best. It’s in an optimum spot for me. It’s super snappy and has good implementation of vim keybindings for manual coding, and it has appropriate AI integration that does all the AI stuff I want without being in my face about how AI it all is.
- marrone12 8mo agoSame, except for me Zed is one of the only editors that has emacs keybindings!
- ffreire 8mo agoAre you familiar with ACP[0]? Through that protocol you can run claude code within zed[1]. Or perhaps I'm not understanding what you mean by using CC integration. [0]: https://agentcommunicationprotocol.dev/introduction/welcome https://agentcommunicationprotocol.dev/introduction/welcome [1]: https://zed.dev/docs/ai/external-agents#claude-code https://zed.dev/docs/ai/external-agents#claude-code
- KingOfCoders 8mo agoACP is so much worse than Claude Code CLI - the quality is not there. Everyone assumes the JSON-CLI-API is the same as the CLI but it is not. Tool usage is different, and I assume agent system prompts are different and agents are different. Integration like in Cursors, I use the CLI and Claude Code knows what files are open, uses Cursor for diffs etc.
- net_ 8mo agoIn 2020, I started working on a (C++) game engine. Since the only decent open-source UI option was Dear ImGui (which was obviously a bad choice for consumer-facing UIs), I ended up rolling my own retained-mode UI library on top of SDL. Now, it's fully-featured enough that I rarely have to touch it. There's even a major company using it for embedded products. I don't get why every language's community doesn't just do the same thing: roll an idiomatic UI lib on top of SDL. It was tough, but I was able to do it as a single person (who was also building an entire game engine at the same time) over the course of a couple years.
- mort96 8mo agoHow's the accessibility?
- net_ 8mo agoI haven't worked on screen reader support, yet. Support for alternative text input is built into SDL. UI size scaling is a feature I plan on adding eventually.
- doodlesdev 8mo ago> I don't get why every language's community doesn't just do the same thing: roll an idiomatic UI lib on top of SDL. > I haven't worked on screen reader support, yet. Support for alternative text input is built into SDL. UI size scaling is a feature I plan on adding eventually. Well, that's why :) For most serious applications, accessibility isn't a second thought, it's a requirement and it's very hard to implement correctly.
- net_ 8mo agoSo the solution is to build applications around less of a common base? I don't follow the logic, with respect to Zed. I get what you mean if there's a first-party UI solution in your language (e.g. Swift), but in that case you don't need an open-source UI library.
- tlhunter 8mo agoHopefully this will get momentum scrolling working.
- raphaelmolly8 8mo ago[dead]
- createaccount99 8mo agoClean change, all things considered. But, like, what? What's to say you won't run into a billion problems here, too?
- n0r0n1n 8mo agoZed ignoring local LLM makes me to sad to worry about the rendering. Not sure why it needs acceleration but willing to learn!
- stephc_int13 8mo agoZed seems to be already suffering from heavy technical debt. From my perspective, as a game dev, their stack is a lot heavier than it should be.
- verdverm 8mo agoThat happens when you don't talk to enough users, build the wrong things, and then iterate like a good startup. It compounds Building a chat platform in an IDE with CRDTs...? That screams we are more interested in the solutions than the problems, and that they didn't appreciate network effect before attempting this
- shimman 8mo agoThey are talking to their users, it's not those that use Zed it's the VC firm that funds them. They seem to be implementing everything those users want.
- verdverm 8mo ago> They are talking to their users If you only talk to the users you already have, you won't know what the users who don't use your product want. Many a project and company have peaked early for this very reason.
- steve_adams_86 8mo agoWhat is the debt? As a user, Zed feels more like the only IDE that isn't weighed down with debt. It's incredibly fast, responsive, stable, and it's iterated on very quickly.
- bhasinanant 8mo agoZed is my goto editor when I'm not vibe coding, but that is rare these days. Their integration with Claude Code, etc really helped, but Antigravity completely pulled me away. And really, since they're catering to the same basic audience, the defaults should be the same as VSCode for most stuff. VSCode but performant would be an excellent pitch for the upcoming consumer RAM deficient world. Dunno how they plan to get wider extensibility and community support without an embedded JS backend to support the existing Code plugins. That's where the real blocker is.
- another_twist 8mo agoCurious: whats your primary programming language and what sort of development do you do ? In my experience with LLMs agentic coding paired with a good IDE works wonders. Its also allows me to surgically write critical bits of code myself while outsourcing boilerplate stuff.
- mercutio2 8mo agoI wonder if the reason that most people don’t agree with me about Antigravity is because you were used to VS Code? For me, Antigravity is possibly the worst GUI experience I’ve had since Clippy. It’s completely filled with arcane buttons, prompts that are effectively modal appear in at least 3 different places, it’s constantly… doing stuff, without any reference to where I should focus my attention. I appreciate Google giving away absurdly generous quantities of tokens for FREE just to get me to use the thing, but I can’t bring myself to, because when I get into the flow of a feature with an LLM, I’m suddenly stuck and can’t figure it out. It’s like peak Google UI for me.
- ruuda 8mo agoI tried Zed for some time. Then it had a regression which broke it completely on my laptop. (Zed can't start any more, logging a PlatformNotSupported error even though earlier versions worked fine.) I carefully bisected it, and it turned out to be due to an intentional change in Blade. The issue was acknowledged, and confirmed by several other users. Then it got converted into a "discussion" because there was nothing actionable to do according to the devs. Then the discussion got closed because they are "directing all support questions to Discord going forward". Then Discord announced mandatory age verification.
- stouset 8mo agoI just did a quick once-over on the PR and am pretty shocked by how "simple" it is. For switching the background graphics library, I would have expected this to be some pretty delicate surgery. But the "meat" is swapping out the old abstraction layer for the new one (500–600LOC) then `s/blade/wgpu/g`. There's a little more to it than that, but not much. I'm already a Zed user, but to me that's an extremely good indicator of the engineering quality of the project.
- RustSupremacist 8mo agoThe GUI situation for Rust is dire. We are still not GUI yet! Even if Rust isn't the best for GUI, the opportunity is still there. Qt is the best option. There isn't a second option. Don't let Go and Zig have bindings for Qt without Rust! Only Rust. Only Cargo. No QML. No C++. No markup. No immediate mode. No dead projects.