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

21–30 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#21

Post by pjmlp »

piker wrote: post #4

Rust 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

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.

Re: Zed editor switching graphics lib from blade to wgpu

#22

Post by flohofwoe »

swiftcoder wrote: post #17
nu11ptr wrote: post #7

Earlier quoted context omitted.

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

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

Re: Zed editor switching graphics lib from blade to wgpu

#23

Post by rafaelmn »

ZeroCool2u wrote: post #3

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

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

Re: Zed editor switching graphics lib from blade to wgpu

#25

Post by piker »

pjmlp wrote: post #21
piker wrote: post #4

Rust 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

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.

I mean, fair enough, but [at least] wikipedia agrees with that take.

> Graphical user interfaces traditionally use retained mode-style API design,[2][5] but immediate mode GUIs instead use an immediate mode-style API design, in which user code directly specifies the GUI elements to draw in the user input loop. For example, rather than having a CreateButton() function that a user would call once to instantiate a button, an immediate-mode GUI API may have a DoButton() function which should be called whenever the button should be on screen.[6][5] The technique was developed by Casey Muratori in 2002.[6][5] Prominent implementations include Omar Cornut's Dear ImGui[7] in C++, Nic Barker's Clay[8][9] in C and Micha Mettke's Nuklear[10] in C.

https://en.wikipedia.org/wiki/Immediate_mode_(computer_graph...

[Edit: I'll add an update to the post to note that Casey Muratori simply “coined the term” but that it predates his video.]

Re: Zed editor switching graphics lib from blade to wgpu

#27

Post by [deleted] »

swiftcoder wrote: post #17
nu11ptr wrote: post #7

Earlier quoted context omitted.

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

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

[deleted]

Re: Zed editor switching graphics lib from blade to wgpu

#28

Post by arandomhuman »

piker wrote: post #25
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.

I mean, fair enough, but [at least] wikipedia agrees with that take. > Graphical user interfaces traditionally use retained mode-style API design,[2][5] but immediate mode GUIs instead use an immediate mode-style API design, in which user code directly specifies the GUI elements to draw in the user input loop. For example, rather than having a CreateButton() function that a user would call once to instantiate a butto…

Wikipedia clearly has never been shown to have faults regarding accuracy.

Re: Zed editor switching graphics lib from blade to wgpu

#29

Post by StilesCrisis »

alphazard wrote: post #26

Can 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?

The old graphics library was basically unmaintained; bug fix PRs were being ignored. WGPU is very actively maintained.

Re: Zed editor switching graphics lib from blade to wgpu

#30

Post by paddy_m »

piker wrote: post #4

Rust 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

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