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

291–300 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#291

Post by Shish2k »

qznc wrote: post #173
the__alchemist wrote: post #93

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

Zed competes mostly against Visual Studio Code. Not against Jetbrains.

I do love jetbrains for its nice-to-have features (eg highlight a few lines in the middle of a spaghetti function -> right click -> extract to new function) and was paying for it out of my own pocket for several years; but had to switch to vscode for a couple of required features that jetbrains was missing (remote dev over ssh, and devcontainers); and now switched to zed for being "like vscode but faster"

Re: Zed editor switching graphics lib from blade to wgpu

#292

Post by throwa356262 »

drannex wrote: post #234
throwa356262 wrote: post #206

Earlier quoted context omitted.

Last time I used zed for go development it spawned nodejs servers (downloaded without asking for permission!) for god knows what. I dont understand the zed hype, not only the UI has tons of issues, memory usage is not that different

> Last time I used zed for go development it spawned nodejs servers (downloaded without asking for permission!) for god knows what. LSPs, they are snagging the LSPs made by other developers for languages you are using. if you install any LSP or language support in VSCode its running the same thing. It only installs when you are using a language that has default support such as Rust, Python (which I believe uses a Nod…

So basically there is no getting away from javascript runtime. So why should I use zed instead of vscode then?

Re: Zed editor switching graphics lib from blade to wgpu

#293

Post by flohofwoe »

conorbergin wrote: post #225
flohofwoe wrote: post #19

Earlier quoted context omitted.

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?

Apparently "joy to use" is one of the new core goals of Khronos for Vulkan. Whether they succeed remains to be seen, but at least they acknowledge now that a developer hostile API is a serious problem for adoption.

The big advantage of Metal is that you can pick your abstraction level. At the highest level it's convenient like D3D11, at the lowest level it's explicit like D3D12 or Vulkan.

Re: Zed editor switching graphics lib from blade to wgpu

#294

Post by qznc »

Shish2k wrote: post #291
qznc wrote: post #173

Earlier quoted context omitted.

Zed competes mostly against Visual Studio Code. Not against Jetbrains.

I do love jetbrains for its nice-to-have features (eg highlight a few lines in the middle of a spaghetti function -> right click -> extract to new function) and was paying for it out of my own pocket for several years; but had to switch to vscode for a couple of required features that jetbrains was missing (remote dev over ssh, and devcontainers); and now switched to zed for being "like vscode but faster"

Zed can "extract function" for Rust code. I guess, it depends on the language server you use? Since vscode and zed use the same there is not distinction between them.

Re: Zed editor switching graphics lib from blade to wgpu

#295

Post by staticassertion »

bmitc wrote: post #275
staticassertion wrote: post #185

Earlier quoted context omitted.

You vastly overestimate the amount of pressure a board can place on an early stage startup. The far more likely scenario to me (someone who raised VC money) is that the CEO likely looked at their run rate and decided to prioritize things more aggressively. This is hardly surprising and it has nothing to do with VCs.

Doesn't it have something to do with VCs? Does the company behind Zed actually make any money on their own?

I mean, in the sense that they are VC funded and so I guess you can tie anything back to VCs? You could just as easily say it has something to do with the founders mother, who gave birth to them.

Re: Zed editor switching graphics lib from blade to wgpu

#296

Post by SigmundA »

pjmlp wrote: post #286
SigmundA wrote: post #227

Earlier quoted context omitted.

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…

I even remember WinG, Win32s and co. You are forgeting most folks did not use bare bones C with WM_PAINT and nothing else. Most sane devs were quick to adopt C++, even Petzold books moved into C++ still during Windows 3.1 days, although the code samples stayed pretty much the C subset common to both languages, see the preface on his book. As such many games had their own retained frameworks built on top of Win32 cont…

I wasn't talking about MFC or VB or any higher level abstraction, I specifically was talking about the base Win16/32 GDI gui system that windows started with.

You can take an immediate mode api and abstract it with a retained mode api. My question was is Win32 / GDI immediate.

There was plenty of pure C windows programs and C++ ones that just used Win32.

ImgGui actually uses a retained mode graphics interface so it only sends changes to the GPU while making it look "immediate" thing is its creating internal state and tracking it so its not smash and replace at the driver level.

Win32 / GDI is mostly smash and replace in WM_PAINT, common controls library will abstract it, but looks a lot like ImgGui in that is uses window handles as ID's for internal state while ImgGui has its ID stack which is just a primitive object state system.

The more I look at ImgGui the less immediate it seems, its just a function based api to a retained mode graphic system that tries to hide the state tracking from you by not always exposing the object handle, mostly.

Re: Zed editor switching graphics lib from blade to wgpu

#297

Post by airstrike »

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

Not at all what they did. iced and Dioxus come to mind

Re: Zed editor switching graphics lib from blade to wgpu

#298

Post by the__alchemist »

jakkos wrote: post #285
the__alchemist wrote: post #93

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

> It sounds like Blade is a cross-API graphics engine, by one of the original gfx-HAL (former QGPU name) creators? My understanding is that wgpu has a lot of constraints and complexity imposed on it by all the backends it has to support (especially WebGPU) and that Blade is meant to be a much simpler closer-to-metal api for people who want more control (and know how to not shoot themselves in the foot) > I would be u…

I appreciate the details!

> Do you mean using egui-wgpu directly rather than through eframe? The default backend of eframe is wgpu (it used to be glow/opengl), and you can still use callbacks to directly render whatever you want with wgpu in an eframe app

I apparently don't know how eframe works... had no idea it used a GPU at all or WGPU under the hood... I assumed it was just the default you use if making a 2d-only program.

Re zed... I think I am too addicted to IDE functionality to be comfortable without. I had assumed Zed could do it, but have now concluded it can't. And/or I can't figure out how to use the LSP features reffed here, or they are well-hidden.

Re: Zed editor switching graphics lib from blade to wgpu

#299

Post by apitman »

piker wrote: post #231
pixelesque wrote: post #222

Earlier quoted context omitted.

Not if you dynamically link it. LGPL.

Is it that simple?

On desktop it can be pretty simple. On mobile it can be a hot mess. Essentially with LGPL you have to provide a way for users to replace your version of the LGPL lib with one they choose.

Also the company seems to be trying to wiggle out from under the open source spirit of the license the last few years, which doesn't bode well.

Re: Zed editor switching graphics lib from blade to wgpu

#300

Post by bmitc »

staticassertion wrote: post #295
bmitc wrote: post #275

Earlier quoted context omitted.

Doesn't it have something to do with VCs? Does the company behind Zed actually make any money on their own?

I mean, in the sense that they are VC funded and so I guess you can tie anything back to VCs? You could just as easily say it has something to do with the founders mother, who gave birth to them.

No, I don't think you could easily say that. You can't say it literally has nothing to do with VCs when VCs are the only reason they're able to keep operating financially.
Post reply on HN