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

Linux When?

zed.dev

Post reply on HN
Print view View original

111–120 of 169 posts

Re: Linux When?

#111

Post by FullGarden_S »

> and we put a lot of effort into understanding macOS APIs to get to 120FPS

If its ultimately a text editor with dead plain UI, why not simply stick to retained mode GUI and chill?

I don't know how much of disk space and ram this written in Rust® text editor project demands to just build it but since its Rust™, achieving cross-platform will probably be several-folds more work than it would be in C, I applaud the devs for their work.

I never tried Zed(yet) and keeping the support for vast programming languages aside, I would like to check out how this editor handles multiple workspaces and provide text editing features. I'm an Emacs guy and I have a feeling that this is not for me because even if its fast, it doesn't make me productive if I'm not using my emacs/vim key bindings. I might be wrong.

Re: Linux When?

#112

Post by zozbot234 »

LoganDark wrote: post #109
adastra22 wrote: post #54

Earlier quoted context omitted.

The question doesn’t make sense. They don’t rerender the buffer every frame. I assume zed isn’t doing that either as it would be horribly inefficient. I presume what is meant is that it can handle a redraw fast enough to be in the next frame. In which case the answer is: all of them. Drawing text is not the bottleneck for a GUI program, unless you have a god awful browser stack as your rendering engine.

> I assume zed isn’t doing that either as it would be horribly inefficient. What are you supposed to do instead? Zed uses the GPU. It's not making calls to retained-mode widgets to individually reposition them, nor is it blitting into a buffer using the CPU. It's using the GPU which eats pixels for breakfast. You've been able to rerender the entire screen each frame for over a decade - just look at Windows 7 Aero, wh…

Rerendering each frame is wasteful because it keeps hardware from reaching deeper power-saving states. This includes the CPU, GPU and even the display, due to technologies such as FreeSync. On modern hardware, even removing the blinking cursor has been found to save quite a bit of power, by eliminating needless screen redraws.

Re: Linux When?

#113

Post by zamalek »

andy_xor_andrew wrote: post #19

> On macOS, for example, Zed makes direct use of Metal. We have our own shaders, our own renderer, and we put a lot of effort into understanding macOS APIs to get to 120FPS. So they are taking the exact opposite approach of Electron (VS Code). In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on L…

> In my mind, if you're someone who types in HN comments in a rage because your text editor

WebGPU exists. It works with Metal. Vulkan could have also worked and MoltenVK would have bridged it to Apple. No, this is just like every other project that only works on MacOS: a mentality I really can't comprehend or explain.

Re: Linux When?

#114

Post by Rusky »

LoganDark wrote: post #109
adastra22 wrote: post #54

Earlier quoted context omitted.

The question doesn’t make sense. They don’t rerender the buffer every frame. I assume zed isn’t doing that either as it would be horribly inefficient. I presume what is meant is that it can handle a redraw fast enough to be in the next frame. In which case the answer is: all of them. Drawing text is not the bottleneck for a GUI program, unless you have a god awful browser stack as your rendering engine.

> I assume zed isn’t doing that either as it would be horribly inefficient. What are you supposed to do instead? Zed uses the GPU. It's not making calls to retained-mode widgets to individually reposition them, nor is it blitting into a buffer using the CPU. It's using the GPU which eats pixels for breakfast. You've been able to rerender the entire screen each frame for over a decade - just look at Windows 7 Aero, wh…

Neither Windows Aero nor Zed renders every single frame, 120 times per second. The parent comment is correct is correct that the important thing is to be able to render any given frame in 1/120th of a second, but to leave things alone when nothing is changing.

Re: Linux When?

#115

Post by gliptic »

jodrellblank wrote: post #92
spudlyo wrote: post #21

From what I understand Zed is a text editor that is built like a game engine, which I understand is why the marketing copy uses the term "multiplayer" rather than "multiuser". I didn't find other mention of its multiplayer capabilities, which is too bad. Has anyone used it for that purpose, I'm curious as to what the experience was like.

"multiplayer notepad" goes back 15 years at least - https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... it was used back with a popular website which opened a text document and anyone viewing could type, but I can't remember the name. That became a thing in Google Docs, Microsoft Office, Floobits, and lots of self-hosted and cloned sites.

IRC was what was initially called multiplayer notepad.

Re: Linux When?

#116

Post by mgaunard »

bioneuralnet wrote: post #55
bovermyer wrote: post #32

Earlier quoted context omitted.

You're aware that Atom is not the subject of the article, right?

I believe some of the Zed folks invented Atom back in the day. But yes, it doesn't seem like a highly relevant comment...

the article doesn't tell me what Zed is. If I look around, it just says it's the new text editor from the authors of Atom.

Re: Linux When?

#117

Post by Iwan-Zotow »

jonhohle wrote: post #24
andy_xor_andrew wrote: post #19

> On macOS, for example, Zed makes direct use of Metal. We have our own shaders, our own renderer, and we put a lot of effort into understanding macOS APIs to get to 120FPS. So they are taking the exact opposite approach of Electron (VS Code). In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on L…

Or… use one of the existing cross platform toolkits that have existed for decades. Text Editors, traditionally, did not require shaders to run or be performant, and not require entire systems worth of RAM.

> Text Editors, traditionally, .. and not require entire systems worth of RAM.

Emacs is looking at you

Re: Linux When?

#118

Post by spudlyo »

jodrellblank wrote: post #92
spudlyo wrote: post #21

From what I understand Zed is a text editor that is built like a game engine, which I understand is why the marketing copy uses the term "multiplayer" rather than "multiuser". I didn't find other mention of its multiplayer capabilities, which is too bad. Has anyone used it for that purpose, I'm curious as to what the experience was like.

"multiplayer notepad" goes back 15 years at least - https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... it was used back with a popular website which opened a text document and anyone viewing could type, but I can't remember the name. That became a thing in Google Docs, Microsoft Office, Floobits, and lots of self-hosted and cloned sites.

You may be thinking of Hackpad from 2014, which later was bought by Dropbox and morphed into Dropbox Paper. I guess I was thinking that a multiuser IDE is substantially different than a multiuser text editor. I did notice that Zed is by the same team that brought us tree-sitter, which is a wonderful innovation that many text editors are now using to good effect. I was wondering if were powerful enough for one person to be debugging some code in the same session that another person was refactoring.

Re: Linux When?

#119

Post by jenadine »

FullGarden_S wrote: post #111

> and we put a lot of effort into understanding macOS APIs to get to 120FPS If its ultimately a text editor with dead plain UI, why not simply stick to retained mode GUI and chill? I don't know how much of disk space and ram this written in Rust® text editor project demands to just build it but since its Rust™, achieving cross-platform will probably be several-folds more work than it would be in C, I applaud the devs…

> since its Rust™, achieving cross-platform will probably be several-folds more work than it would be in C,

Why would you think that? Rust is a more expressive and powerful language than C. If anything, I'd say it would be easier. Platform APIs are not all in C either.

Re: Linux When?

#120

Post by littlestymaar »

jauntywundrkind wrote: post #91
jamil7 wrote: post #85

Earlier quoted context omitted.

Cross platform toolkits, more than other software components incur massive tradeoffs. They’ve written one themselves, tailored to their needs and open sourced it along the way. I guess I don’t see the problem here. If one that’s existed for decades fits your needs better then use that.

Wgpu seems very very well loved & supported, is one of the most successful comings together of the graphics world in ages. I'd love to hear some actual critique of it, hear what people think are shortcomings, because it feels to an outsider like this is the fantasy land, that we're living in the better place now. https://github.com/gfx-rs/wgpu

What I find interesting is that kvark, the open source contributor that made Linux port possible was the main developer on wgpu at Mozilla, yet he decided to build an alternative [1] to wgpu that he used for zed. I wonder what's the rational for that.

[1]: https://github.com/kvark/blade

Post reply on HN