Live data from Hacker News

Linux When?

zed.dev

161–169 of 169 posts

Re: Linux When?

#161

>Yup, that's a native file dialog, but we don't use GTK in Zed and that clearly is GTK — so, how does that work? You'll find the answer in the companion video in which Mikayla and I dive deeper into this and also touch on the question of whether or not we should use GTK or Qt or something else (spoiler: it's complicated). Unless I missed it, the video doesn't actually answer the question. They talk 38:50 onwards abou…

They seem to mention Portals at 10:41 ("Show Transcript", Ctrl+F "portal"): https://youtu.be/O5XVVnA2LoY?t=641

Re: Linux When?

#162

Earlier quoted context omitted.

It's just common online courtesy to add to the title a short description of the project like (Zed, code editor) to save users some valuable time.

And it's in the HN guidelines not to: https://news.ycombinator.com/newsguidelines.html > please use the original title, unless it is misleading or linkbait; don't editorialize. > If the title includes the name of the site, please take it out, because the site name will be displayed after the link. > Please don't do things to make titles stand out, like using uppercase or exclamation points, or saying how great an art…

[deleted]

Re: Linux When?

#163
I switched to using Zed recently and quite like it. There are definitely teething problems dealing with all of the different user and tooling configurations out in the wild, but it does feel significantly faster than VSCode. I'm only missing a few things from VSCode (like inline test runners and bazel plugins). I'm looking forward to their take on dev containers / remote dev too.

I hope they survive as a company!

Re: Linux When?

#164

Earlier quoted context omitted.

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

GGP is me, and yes that’s what I meant. Under no circumstance would zed actually be drawing 120 frames each second, right? That would be 100x more energy usage than would actually be required, and so I think “horribly” is accurate.

Re: Linux When?

#165
post #159

Earlier quoted context omitted.

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…

It's hard to tell the difference with smooth motion.

With rendered frames, the stuttering makes it meaningfully harder to click on fast moving things.

> And the use case at hand is text editting!

People were being dismissive about frame rates in general, so I gave an example that wasn't test editing.

The benefit for text editing is much smaller, but also if you're text editing then you don't need significant amounts of compute power to do text at 120. One big criticism disappears. You need that power for games, which actually benefit.

I've used 4k at 30Hz before, but I switched it to 60Hz with chroma subsampling for faster things.

> As far as 4k, not sure I understand?

They're both good but not necessary, and partly situational. But you're choosing to ignore the benefits of one.

A curmudgeon should dismiss both, and most people should want both.

Re: Linux When?

#167

Earlier quoted context omitted.

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

GGP is me, and yes that’s what I meant. Under no circumstance would zed actually be drawing 120 frames each second, right? That would be 100x more energy usage than would actually be required, and so I think “horribly” is accurate.

> GGP is me

Oops, thanks for the correction.

> Under no circumstance would zed actually be drawing 120 frames each second, right?

It does this when scrolling for sure. That's a trivial case where 120 FPS is required on a 120Hz display.

It also does this even when nothing on the screen is changing, but only for about 1 second after the last user input. This is explained in a blog post[0].

Now this does cause more power usage, because when Zed does not do this, the display can actually downclock to save power. But downclocking like that increases latency, which is why they prevent it from happening in the middle of user input (but still allow it to happen betwen each burst of input).

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

Re: Linux When?

#168
post #134

Earlier quoted context omitted.

Heh, rocking a self built tmux/vim setup her myself, but even still I don't think I'm so cynical to think the only reason is for the marketing speak. I assume they have a reason, I just can't guess whatnot is.

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.

Not really, 120Hz produces a noticeable improvement over 60Hz, unlike "golden boutique speaker wire", just like 4k produces a noticeable improvement over 1080p.

It's not like everyone is going to be able to tell whether a given display is 60Hz or 120Hz, but all other things being identical, they will probably be able to tell which display is faster after using both.

Higher refresh rates tighten the feedback-response loop, creating a smoother and more direct interface to the computer, which is generally perceived as desirable.

Consider VR, where HMDs often have to refresh at 90Hz or 120Hz in order to reduce motion sickness. This actually isn't that different than operating a computer. The brain tends to quickly get very upset when it can't reconcile your visual field with your felt position in space, but even though most people don't get motion sick from looking at a computer display (some do), the refresh rate certainly affects it feels to use the display.

Re: Linux When?

#169

Earlier quoted context omitted.

It's a blog post directly on their website. Is it really unreasonable to need to click to the home page for more context?

At the time you posted this comment, there was no link to the home page for mobile devices. Also, on mobile devices it's a pain to edit the URL in the address bar. You could have gone to the About page, but there's no summary. You'd gather right away that this was about an editor, but you'd have to read quite a bit about history, goals, etc. before you find out what differentiates this editor from any other editor.

Fair. I checked the site on my laptop and the logo at the top left easily got me to the homepage that described the editor.
Post reply on HN