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.
This ain't my turf so apologies for inaccuracies here. It appears to be a fairly novel attempt to write a graphics library with a semi conventional looking pipeline, that under the hood ends up eskewing a lot of the Vulkan concepts. Instead of per object contexts, it uses global contexts to do most work. Instead of taking resources and binding them into descriptor sets to use across pipelines (tracking state), Blade kind of recreates resources on the fly, lets them get used, and disposed of them.
Kind of interesting philosophy of a complex binding model in Vulkan/WebGPU vs a more direct diy render model?
https://www.youtube.com/live/63dnzjw4azI?si=KzLPm-gBX0gDKq7H...
Zed tool this work as an outside contribution. Maybe that someone did the work was good enough. I'm not sure what would make Blade a better match or not, vs wgpu-hal.
(honest question - I've never looked into it myself)
For me, it's animations, especially if I'm dragging a window or just the mouse. On 60hz it's nauseating if I'm paying too much attention to the window I'm moving. It's goes completely away around 90-100 Hz (at least for me)
I do not suffer from nausea or motion sickness of any kind arising from computers or visuals in general, but I can still easily tell the difference between a 60Hz and 90Hz display. A few months ago I had the privilege of checking out the 120Hz displays on the new MacBooks and they're amazing.
And I also count myself as someone who considers 120 at least necessary (on the primary monitor)
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.
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, which ran on the laptops of 2009 for the exact same reason: it used the GPU!
Hadn't heard of that before, but it makes sense now you mention it. :)
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).
I can't think or type that fast and I can't read scroll back that fast either so I can't wrap my head around needing something like that.
More-honest-than-it-should-be answer: sell a product to Apple-ecosystem developers trying desperately to find something to justify the $3k they want to spend on a new MBP.
(Typing this very comment in emacs running out of the Linux VM on a mid-range chromebook attached to a 30 Hz 4k television, btw. Come at me, as it were.)
I assume they have a reason, I just can't guess whatnot is.
Your cynicism over 120Hz should match your cynicism over 4k.
I'm not saying to be highly cynical, I'm saying to be equally cynical. You can change either side to reach equality.
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).
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.
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.
It also seems like you can configure VSCode to go faster: https://stackoverflow.com/questions/52230196/vs-code-is-visi...
But honestly, 'responsiveness' should come from not blocking the main/UI threads, and rendering in the right order of importance.
Emacs is looking at you