Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zed editor switching graphics lib from blade to wgpu

github.com

Post reply on HN
Print view View original

221–230 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#221

Post by Ygg2 »

meindnoch wrote: post #208
kllrnohj wrote: post #96

Earlier quoted context omitted.

There's also good reasons that immediate mode GUIs are largely only ever used by games, they are absolutely terrible for regular UI needs. Since Rust gaming is still largely non-existent, it's hardly surprising that things like 'egui' are similarly struggling. That doesn't (or shouldn't) be any reflection on whether or not Rust GUIs as a whole are struggling. Unless the Rust ecosystem made the easily predicted terrib…

>Unless the Rust ecosystem made the easily predicted terrible choice of rallying behind immediate mode GUIs for generic UIs... That's exactly what they did :D

They didn't. Biggest Rust GUI by popularity is Dioxus.

Re: Zed editor switching graphics lib from blade to wgpu

#222

Post by pixelesque »

piker wrote: post #200
saghm wrote: post #124

Earlier quoted context omitted.

I 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 ha…

Qt is great, but it's a commercial license.

Not if you dynamically link it. LGPL.

Re: Zed editor switching graphics lib from blade to wgpu

#223

Post by Barrin92 »

tptacek wrote: post #178
laweijfmvo wrote: post #104

Earlier quoted context omitted.

> We gotta focus on some business relevant work in 2026 Remember that post announcing the millions of VC capital they raised? This is the result

What's that, doing actual work rather than labor-of-love open source stuff? Seems reasonable. Did you not raise a bunch of money from Sequoia? Sounds like you're in a perfect place to quit your job and hack on GPUI for us.

>What's that, doing actual work rather than labor-of-love open source stuff?

except the 'labor-of-love' stuff is what set the editor apart and why real users were choosing it and the 'actual business work' the moneymen are eager about is exactly what's in every other editor and what nobody asked for

Re: Zed editor switching graphics lib from blade to wgpu

#224

Post by [deleted] »

Jtsummers wrote: post #61
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.

It's like the common claim that data-oriented programming came out of game development. It's ahistorical, but a common belief. People can't see past their heroes (Casey Muratori, Jonathon Blow) or the past decade or two of work.

[deleted]

Re: Zed editor switching graphics lib from blade to wgpu

#225

Post by conorbergin »

flohofwoe wrote: post #19
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.

For 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_hea…

Do you think Vulkan will become "nice" to use, could it ever be as ergonomic as Metal is supposed to be?

Re: Zed editor switching graphics lib from blade to wgpu

#226

Post by ChadNauseam »

swiftcoder wrote: post #89
vitorsr wrote: post #34

Earlier quoted context omitted.

Please elaborate, I am curious to why would you think WebGPU would meaningfully beat their Metal/DirectX renderers.

I 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

wgpu isn't a renderer though, it's an abstraction layer. It's honestly hard for me to imagine it ever being faster than writing directx or metal directly. It has many advantages, like that it runs in browsers and is memory safe (and in the case of dawn, has great error messages). But it's hard for it to ever be as fast as the native APIs it calls for you.

Re: Zed editor switching graphics lib from blade to wgpu

#227

Post by SigmundA »

pjmlp wrote: post #195
SigmundA wrote: post #170

Earlier quoted context omitted.

Is Win16 / Win32 GDI which goes back to 1985 an immediate mode GUI? Win32 GUI common controls are a pretty thin layer over GDI and you can always take over WM_PAINT and do whatever you like. If you make your own control you musts handle WM_PAINT which seems pretty immediate to me. https://learn.microsoft.com/en-us/windows/win32/learnwin32/y... Difference between game engine and say GDI is just the window buffer inval…

No, that is event based programming, and also the basis of retained rendering, because you already have the controls that you compose, or subclass. Handling WM_PAINT is no different from something like OnPaint() on a base class. This was actually one of mindset shifts when moving from MS-DOS into Windows graphics programming.

Event based or loop based is separate from retained or immediate.

The canvas api in the browser is immediate mode driven by events such as requestAnimationFrame

If you do not draw in WM_PAINT it will not redraw any state on its own within your control.

GDI is most certainly an immediate mode API and if you have been around long enough for DOS you would remember how to use WM_PAINT to write a game loop renderer before Direct2D in windows. Remember BitBlt for off screen rendering with GDI in WM_PAINT?

https://learn.microsoft.com/en-us/windows/win32/direct2d/com...

Re: Zed editor switching graphics lib from blade to wgpu

#228

Post by badhorseman »

logicprog wrote: post #217
badhorseman wrote: post #50

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

It's not clear to me why you would want your editor to run in as many environments as possible unless you're a system administrator? Generally, most of us do our serious coding work on the major OS platforms and we would want a native editor that takes advantage of those platforms and the hardware they tend to run on maximally; if we need to edit something on some other box elsewhere, we could either use Zed's remote…

> It's not clear to me why you would want your editor to run in as many environments as possible unless you're a system administrator?

All I really was trying to say is that one may find themselves in a more limited environment at some points, I was not so much thinking of remote editing for the reason you mentioned that most developers or even system admins(unless restricted for security reason or some other) can just remote in and most editors these days do this well. but in a situation where one may be installing their system or their graphics acceleration has broken for what ever reason and now one is without their trusty editor so although I hardly every use emacs in a tty or pty it's a fallback in case something goes wrong so I can fix it while still using my editor.

>that the editor can open 60,000 line code files instantaneously syntax highlight all of it using trees that are and be butter smooth and responsive the entire time I'm searching through making multi-cursor edits or moving through the file.

this definitely sounds interesting, emacs when dealing with very large log files and such is not always fantastic and some features become painfully slow or completely unusable .

Your other points on the AI features are interesting I have been using Aider and tried aidermacs but ended up going back to a shell buffer with some basic commands to switch back to the buffer and other features to control it, while in one of the code buffers. So will definitely look at some of the AI features when I give it a spin.

Re: Zed editor switching graphics lib from blade to wgpu

#229

Post by mort96 »

net_ wrote: post #183
doodlesdev wrote: post #171

Earlier quoted context omitted.

> 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 c…

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

The solution, if you want a production ready GUI, is to use a GUI toolkit which already has decent accessibility support.

There aren't that many of those: .NET, AppKit/UIKit, SwiftUI, Qt, GTK, the web, wxWidgets (which is really just GTK/AppKit/.NET), probably a couple others. So you either use the native language of one of those toolkits, or you use bindings from your language to those toolkits.

Re: Zed editor switching graphics lib from blade to wgpu

#230

Post by torginus »

dijit wrote: post #175
duped wrote: post #168

Earlier quoted context omitted.

I don't really like this line of discourse because few domains are as ignorant of computing advances as game development. Which makes sense, they have real deadlines and different goals. But I often roll my eyes at some of the conference talks and twitter flame wars that come from game devs, because the rest of computing has more money resting on performance than most game companies will ever make in sales. Not to me…

I mean... fair point? I'm not claiming games are uniquely performance-critical. You're right that HFT, large-scale backend, and real-time systems care deeply about performance, often with far more money at stake. But those domains are rare. The vast majority of software development today can genuinely throw hardware or money at problems (even HFT and large backend systems). Backends are usually designed to scale hori…

I think we as software developers are resting on the shoulders of giants. It's amazing how fast and economical stuff like redis, nginx, memcached, and other 'old ' software are written decades ago, mostly in C, by people who really understood what made them run fast (in a slightly different way to games, less about caches and data, and more about how the OS handles low level primitives).

A browser like Chrome also rests on a rendering engine like Skia, that has been optimized to the gills, so at least performance can be theoretically fast.

Then one tries to host static files on a express webserver, and is suprised to find that a powerful computer can only serve files at 40MB/s with the CPU at 100%.

I would like to think that a 'Faustian deal' in terms of performance exists - you give up 10,50,90% of your performance in exchange for convenience.

But unfortunately experience shows there's no such thing, arbitrarily powerful hardware can be arbitrarily slow.

And as you contrast gamedev to other domains who get to hide latency, I don't think its ok that a simple 3 column gallery page takes more than 1 second to load, people merely tolerate this not enjoy it.

And ironically I find that a lot of folks end up optimizing their React layouts way more than what it'd have cost to render naively with a more efficient toolkit.

I am also not sure what advances game dev is missing out on, I guess devs are somewhat more reluctant to write awful code in the name of performance nowadays, but I'd love to hear what advances gamedev could learn from the broader software world.

The TLDR version of what I wanted to say, is I wish there was a linear performance-convenience scale, where we could pick a certain point and use techniques conforming to that, and trade two thirds of the max speed for dev experience, knowing our performance targets allow for that.

But unfortunately that's not how it works, if you choose convenience over performance, your code is going to be slow enough that users will complain, no matter what hardware you have.

Post reply on HN