[deleted]
Xi-Editor Retrospective
101–110 of 162 posts
Re: Xi-Editor Retrospective
#102Is there another modern editor like Xi that strictly separates the GUI front end (view) from the backend (model and controller)?
neovim is the pioneer here.
Re: Xi-Editor Retrospective
#103Earlier quoted context omitted.
Still feels like that should not be the case. What changed so heavily in the last decade? 2d rendering used to be hella fast without the gpu. Right?
Rendering models & expectations changed. Once upon a time (a decade ago) it was OK for apps to directly draw to the front window, compositing wasn't a super established thing. This saves on precious memory bandwidth, which CPUs didn't really get all that much more of over the last decade. However now that GPU composition has to happen, GPUs actually don't super like the linear formats that CPUs write to. They want sw…
What kllrnohj says here. There are other trends as well. Because bandwidth was considered a very scarce resource, apps used to do very fine-grained dirty region tracking, and be very careful to update only what really changed (again, often by painting on the front buffer directly). Scrolling was often handled by an explicit bitblt operation, which commonly had hardware support even on very early computers.
For complex reasons, that's all been changing. For example, Metal on macOS doesn't even have a way to specify partial screen updates. Those optimizations are still valid, though, and in my ideal world we have both good support for partial invalidation and fast GPU rendering. Among other things, that would be really good for power usage. But to get there requires some attention to detail that seems to be mostly gone from the desktop UI space.
Re: Xi-Editor Retrospective
#104Is there another modern editor like Xi that strictly separates the GUI front end (view) from the backend (model and controller)?
neovim is the pioneer here. https://neovim.io
Thanks, I didn't realize neovim had this. I found this article that explains the embed feature: https://tarruda.github.io/articles/neovim-smart-ui-protocol/
Re: Xi-Editor Retrospective
#105Earlier quoted context omitted.
Rendering models & expectations changed. Once upon a time (a decade ago) it was OK for apps to directly draw to the front window, compositing wasn't a super established thing. This saves on precious memory bandwidth, which CPUs didn't really get all that much more of over the last decade. However now that GPU composition has to happen, GPUs actually don't super like the linear formats that CPUs write to. They want sw…
Do you have any good reads on the difference in format that you are referencing? (Linear versus whatever the gpu is doing?) Even sending the buffer to the gpu for compositing makes sense as a problem, but still feels that should be faster than you would care about in a text editor. I'm also on a mac that, if I do something that is "gpu accelerated", I'm likely to get a frozen session. Such that most applications don'…
Very likely, the specific thing you're experiencing is poorly-engineered switching between integrated and discrete GPUs. It's not a mac-only problem, see this thread for a somewhat horrifying story (follow last link): https://www.reddit.com/r/gigabyte/comments/91ld3o/aero_15x_d...
A good intro to layout transitions is: https://www.gamasutra.com/blogs/EgorYusov/20181211/332596/Ta...
The number of copies required to get a pixel from CPU space into photons today is ridiculous. It used to be you'd just write into a memory-mapped buffer, and your graphics card would scan out directly from that where it would get to the electron beam modulator in microseconds.
Re: Xi-Editor Retrospective
#106The assertion that gpu is required for good text rendering caught me off guard. I can't claim it is wrong, but it does feel like it should be wrong.
Sublime Text 3 still exclusively uses CPU rendering. Unless you're working with really high resolutions (think 8k), CPU rendering is plenty fast.
Re: Xi-Editor Retrospective
#107Earlier quoted context omitted.
> as a side note, i think more and more people are starting to realize that the async paradigm is not a panacea. This is why libvim (from the oni2 project) is based on vim rather than neovim. Even aside from performance, it is a huge simplification if you can interact with an editor engine in the same process, synchronously. At some point we replaced simple function calls with baroque APIs accessed over localhost...
It's not that cut and dry. See https://github.com/onivim/libvim#why-is-libvim-based-on-vim-... It's mostly due to their build system.
I've seen that but Bryan said this just a few days ago:
> This was a smaller consideration - but more fundamentally, the model Neovim uses for input - queuing it on an event loop and handling it asynchronously - is at odds with what we required - to be able to process the input -> handle updates synchronously.
Re: Xi-Editor Retrospective
#108Earlier quoted context omitted.
Rendering models & expectations changed. Once upon a time (a decade ago) it was OK for apps to directly draw to the front window, compositing wasn't a super established thing. This saves on precious memory bandwidth, which CPUs didn't really get all that much more of over the last decade. However now that GPU composition has to happen, GPUs actually don't super like the linear formats that CPUs write to. They want sw…
Do you have any good reads on the difference in format that you are referencing? (Linear versus whatever the gpu is doing?) Even sending the buffer to the gpu for compositing makes sense as a problem, but still feels that should be faster than you would care about in a text editor. I'm also on a mac that, if I do something that is "gpu accelerated", I'm likely to get a frozen session. Such that most applications don'…
> Do you have any good reads on the difference in format that you are referencing? (Linear versus whatever the gpu is doing?)
Linear is just your normal buffer where you index into a pixel at '(y * stride) + x', where stride is probably just the width * bytes per pixel.
But this isn't how GPUs store texture data. They swizzle it so that locality can be maintained well enough regardless of how the texture is rotated. httsp://fgiesen.wordpress.com/2011/01/17/texture-tiling-and-swizzling/ is a decent introduction. https://en.wikipedia.org/wiki/Z-order_curve has more of the general side of things.
There's then also framebuffer compression in addition to all this.
Re: Xi-Editor Retrospective
#109> First, TextMate / Sublime style syntax highlighting is not really all that great. It is quite slow, largely because it grinds through a lot of regular expressions with captures, and it is also not very precise.
The tree-sitter framework provides a pretty good engine for syntax highlight:
Re: Xi-Editor Retrospective
#110What is the successful text-editor project in Rust now? Xray seems to have been abandoned too.