- cross-posted to:
- programming@programming.dev
- foss@beehaw.org
- cross-posted to:
- programming@programming.dev
- foss@beehaw.org
Zed is a modern open-source code editor, built from the ground up in Rust with a GPU-accelerated renderer.
Zed is a modern open-source code editor, built from the ground up in Rust with a GPU-accelerated renderer.
I still don’t understand why I should need GPU acceleration for my fucking TEXT EDITOR
Probably because it’s more efficient. GPUs are designed to render things, which editors do. In a text editor, you’re effectively rendering fonts over a fixed background, which I assume is pretty efficient using the GPU.
We’re not talking about crazy 3D effects here.
Yay to battery savings!
Shouldn’t the DE/Window Manager be handling that? Seems like doing it on a window by window basis would be inefficient (and look inconsistent).
That’s a totally unrelated part of the stack. These days you just have a compositor that combines the output of applications.
The model of out of process rendering in Xorg was done pre-2000s but GPUs became the norm and don’t work well this way.
Thats where we get into explicit and implicit sync right?
Also very unrelated, that’s about graphics apis like opengl.
https://www.khronos.org/opengl/wiki/Synchronization
The job of the window manager is to manage windows and very little else. Font rendering is done by the widget toolkit, usually via freetype/harfbuzz.
Same reason you need it for your terminal (see kitty terminal). It’s surprisingly slow to cpu render text, gpu rendering is more power efficient and far more responsive
It was surprising how gpu accelerated rendering helped read logs better. Niche case, but better was better.
Better in what sense?
More readable on my part. The speed at which logs could write to the screen and still be readable was faster for me compared to before.
Interesting! I’d like to experience this at some point.
Surprisingly slow compared to GPU rendering. But… is it really “surprisingly slow”? If it was some 10mhz machine, then sure… I’d agree with you.
Look at the benchmarks on kitty https://sw.kovidgoyal.net/kitty/performance/
Maybe I’m missing something, but shouldn’t the benchmark be a good approximation to the real workload? I don’t see how the measurements reflect the performance difference in real life usages.
Why would I need 100MiB/s processing as opposed to 20MiB/s processing, when I can only read maybe several lines per second?
Faster processing means more efficient processing which means less power draw.
https://github.com/kovidgoyal/kitty/issues/2701#issuecomment-911089374
How about keypress latency? Over 3x faster than gnome terminal and 4x faster than alacritty
So I don’t.
Sppeeed
Think about battery life too 🎉
I mean, it should be clear. Smooth and fast and snappy. If you don’t want that, use neovim like me :)
But… Neovim is smooth, fast and snappy 😭
Terminals applications are, by definition, not smooth. You can’t have smooth scrolling, or anything else really, with a text grid.
Idk I’m so used to working in terminal I don’t really notice that. For my eyes, it’s smooth enough
Hold down
jand lmk how smooth it is 😅😭😭😭
Smooth scrolling? Maybe I’m wrong