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

151–160 of 169 posts

Re: Linux When?

#151

Post by justinclift »

zozbot234 wrote: post #112
LoganDark wrote: post #109

Earlier quoted context omitted.

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

> ... even removing the blinking cursor has been found to save quite a bit of power, by eliminating needless screen redraws.

Hadn't heard of that before, but it makes sense now you mention it. :)

Re: Linux When?

#152

Post by WuxiFingerHold »

mhaberl wrote: post #39

Serious question: I am looking at the measurements of speed on the landing page between Zed and the other editors, and they don't seem drastic. Do you actually feel the difference when typing?

No. However, VS Code sometimes freezes shortly. Maybe some GC stuff going on. But when both VS Code and Zed have finished starting (Zed of course faster) and you start typing, you don't feel a difference (unless you're on a very slow computer I guess). At least I don't. Same with Neovim.

I don't get this. There are so many things that Zed does better than VS Code, but typing latency is the least noticeable and interesting.

Re: Linux When?

#153

Post by WuxiFingerHold »

bioneuralnet wrote: post #43
mhaberl wrote: post #39

Serious question: I am looking at the measurements of speed on the landing page between Zed and the other editors, and they don't seem drastic. Do you actually feel the difference when typing?

Compared with VSCode, absolutely. VSCode has a range of responsiveness from "good enough" to "oh right, this is Electron". Zed is both faster and more consistent. Sure, we're talking 10s of milliseconds, but it's surprisingly noticeable. Can't speak for other editors. I'm becoming a true convert, though I occasionally must drop down to a termianl for advanced vim features. That's high praise coming from me, as I have…

Agree with the "hanging" and general responsiveness issues with VS Code, but typing (when VS Code is not taking a nap)? No way. Pure typing is not distinguishable.

Re: Linux When?

#154

Post by LoganDark »

zozbot234 wrote: post #112
LoganDark wrote: post #109

Earlier quoted context omitted.

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

Zed only rerenders the window each time it changes (and also for about a second since the last interaction for reasons[0]) but every time it rerenders the window it does rerender the entire window and not just the area that changed. That's what I thought GGP was calling horribly inefficient.

[0]: https://zed.dev/blog/120fps

Re: Linux When?

#155

Post by LoganDark »

Rusky wrote: post #114
LoganDark wrote: post #109

Earlier quoted context omitted.

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

Zed does do it for about a second following user interaction[0] but I assumed GGP was talking about only redrawing the changed part of the window. Not rendering frames continuously even when nothing is changing at all, which Zed doesn't do (and Windows Aero didn't either, at least to a certain extent).

[0]: https://zed.dev/blog/120fps

Re: Linux When?

#156

Post by LoganDark »

adastra22 wrote: post #129
LoganDark wrote: post #109

Earlier quoted context omitted.

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

You render into a texture once, and then just send that to the compositor each frame as needed.

Yes, it's just rendering into the texture redraws the entire window and you never really need to worry about redrawing only the parts of the screen that changed. But I think GGP was actually talking about redrawing the window every frame even if nothing's changed at all, which is indeed inefficent (though not necessarily "horribly").

Re: Linux When?

#157

Post by mgaunard »

FireBeyond wrote: post #141
mgaunard wrote: post #116

Earlier quoted context omitted.

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.

> doesn't tell me what Zed is. If I look around, it just says it's the new text editor Huh. Did you mean to disagree with yourself the very next sentence?

If I look around elsewhere than the article.

Basically I have no reason to be interested in another Atom clone, and there is no sell in this article that explains why I should care.

Re: Linux When?

#158

Post by bovermyer »

mgaunard wrote: post #157
FireBeyond wrote: post #141

Earlier quoted context omitted.

> doesn't tell me what Zed is. If I look around, it just says it's the new text editor Huh. Did you mean to disagree with yourself the very next sentence?

If I look around elsewhere than the article. Basically I have no reason to be interested in another Atom clone, and there is no sell in this article that explains why I should care.

Zed is written in Rust.

You're not the target audience. Move along.

Re: Linux When?

#159

Post by ajross »

Dylan16807 wrote: post #137
ajross wrote: post #134

Earlier quoted context omitted.

I'm... absolutely that cynical. 120 Hz displays and the horsepower to drive them are the golden boutique speaker wire of the Gen Z tech set.

Oh come on. Fancy wires do nothing. 120Hz makes motion much smoother. It also reduces latency. Those make a big difference in many video games, or even just moving my mouse around and having it not skip two inches at a time. Your cynicism over 120Hz should match your cynicism over 4k.

Your mouse cursor aliasing test is sort of the tell here. Normal human beings are very hard put to be able to even detect the difference between a 60 Hz and 120 Hz display, and have to resort, as you do, to trickery and artifacts to measure it. And the use case at hand is text editting!

As far as 4k, not sure I understand? It's not a nonsense retina tablet or whatever, it's a 42" television with 100 DPI pixels I can see with my own eyes (well, when I put my reading glasses on -- presbyopia comes for us all). I bought it because it's cheap and it subtends 60 degrees of pixels small enough to be unresolvable, and sits farther than an arms length from my eyes (presbyopia again).

Re: Linux When?

#160

Post by zamalek »

pjmlp wrote: post #147
zamalek wrote: post #113

Earlier quoted context omitted.

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

Developed for Web browsers, targeting managed languages, and hardware specifications from 2015.

The reference WebGPU implementation is in Rust. It's what Bevy, and many other Rust game engines, uses. All discoverable with 5 seconds of google.
Post reply on HN