Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xi: an editor for the next 20 years [video]

recurse.com

Post reply on HN
Print view View original

111–120 of 306 posts

Re: Xi: an editor for the next 20 years [video]

#111

Post by z3t4 »

c-smile wrote: post #98

"Platform text rendering (CoreText, DirectWrite) not performant enough" That above needs some reliable proof to be honest. I am testing this claim with Sciter ( https://sciter.com )... On Windows Sciter uses Direct2D/DirectWrite (with an option to render on DirectX device directly) and/or Skia/OpenGL. On Mac it uses Skia/OpenGL with an option to use CoreGraphics. On Linux Cairo or Skia/OpenGL. Here is full screen tex…

platform rendering is very hard to beat. i tried to make my own bitmap text rendering but the native is much faster. and you wont notice any difference between 1ms and 10ms due to monitor refresh rate and human perception. text editors like notepad++ and sublime is already at ~5ms input latency. i think text rendering is already a solved problem. and not the bottleneck in for example browser based text editors.

Re: Xi: an editor for the next 20 years [video]

#112

Post by c-smile »

vardump wrote: post #101
c-smile wrote: post #98

"Platform text rendering (CoreText, DirectWrite) not performant enough" That above needs some reliable proof to be honest. I am testing this claim with Sciter ( https://sciter.com )... On Windows Sciter uses Direct2D/DirectWrite (with an option to render on DirectX device directly) and/or Skia/OpenGL. On Mac it uses Skia/OpenGL with an option to use CoreGraphics. On Linux Cairo or Skia/OpenGL. Here is full screen tex…

> On window caption you see real FPS that is around 500 frames per second for the whole screen for the sample. Sure, 500 fps, but that's not the important part. Latency would be. So at 500 fps with how much output latency to the display?

For that particular text editor latency of char typed to appear on screen will be 16ms (normal 60 FPS refresh rate).

Editor keeps each line in separate DOM elements (like

but no margins and only text inside).

So we just need to relayout one particular line in order to show typed character.

Re: Xi: an editor for the next 20 years [video]

#113

Post by jarpineh »

raphlinus wrote: post #11

Presenter here, feel free to ask questions. Also thanks to the awesome Recurse Center for inviting me to speak and making the recording, and the audience for their great questions.

Latency and multi-process editing environment has been on my radar recently. Programming languages providing analysis servers, external syntax highlighters and of course REPLs all benefit from editor that’s fast and async. Since Jetbrains editors brought zero latency writing to my attention I’ve begun to notice which apps seem to hinder my writing. It’s getting easier to build your own editing system instead of having to accept full product from one vendor (Jetbrains tools are great, but very hard on my poor machine…). For this I’ll be watching Xi closely.

I’m in the process of learning Kakoune (1) which happens to have JSON-RPC API as well (2). Kak is fully terminal app which doesn’t give it any edge on latency (doing low latency terminals and shells seems to be a hard task). Hopefully Kak’s take on Vi’s commands as selection oriented language can be leveraged from within Xi editing framework in some capacity.

(1)[http://kakoune.org] (2)[https://github.com/mawww/kakoune/wiki/JSON-RPC]

Re: Xi: an editor for the next 20 years [video]

#114

Post by raphlinus »

c-smile wrote: post #98

"Platform text rendering (CoreText, DirectWrite) not performant enough" That above needs some reliable proof to be honest. I am testing this claim with Sciter ( https://sciter.com )... On Windows Sciter uses Direct2D/DirectWrite (with an option to render on DirectX device directly) and/or Skia/OpenGL. On Mac it uses Skia/OpenGL with an option to use CoreGraphics. On Linux Cairo or Skia/OpenGL. Here is full screen tex…

I'll have to try this out. My experiments indicated that DirectWrite could not keep up with drawing on a 4k monitor at 60 Hz, though was ok at a smaller window. I think it might depend a lot on driver too. I'll see if I can instrument the xi-win prototype to give performance numbers. I do note that your lines aren't very wide, but still, in my tests I wasn't seeing anything like 500fps. DirectWrite does at least seem to use the GPU, while Core Text appears to rely entirely on software rendering.

Skia is definitely capable of good performance, as it resolves down to OpenGL draw calls, pretty much the same as Alacritty, WebRender, and now xi-mac. One thing though is that it doesn't do fully gamma-corrected alpha compositing, so it's not anywhere near pixel-accurate to CoreText rendering.

Doing proper measurement is not easy, but seems worth doing.

Re: Xi: an editor for the next 20 years [video]

#115

Post by wll »

gnachman wrote: post #95
eeks wrote: post #18

Earlier quoted context omitted.

I must concur. With an equivalent vim setup and code files, nothing beats X11/suckless terminal on my OpenBSD machine. Comparing to that, even Alacritty looks like a slug. I must say however that things are looking a bit better in iTerm2 when switching the Metal renderer on. It's just a shame that an Nvidia GPU on OSX is necessary to compete with my $1000 Lenovo with its crappy Intel chip on OpenBSD when it comes to…

iTerm2's design is saddled by some history. At the time I took it over, everything was done in a single thread. By the time I realized I was going to stay with the project and how bad the design was, it was too late to change it. I've moved as much work as possible off the main thread (parsing the bytestream and now rendering). I think Terminal gets very nice performance without resorting to Metal by doing only UI wo…

Thank you for your work on iTerm2, George!

Re: Xi: an editor for the next 20 years [video]

#116

Post by bedros »

How small the binaries are, with a GUI (GTK, KDE, or QT), if I need to install in a system with no root permissions (local install) that's what I like about sublime, I can install it in home directory without needing admin help.

would you support plugins in a scripting language like python?

Re: Xi: an editor for the next 20 years [video]

#117

Post by tomcooks »

mattgreenrocks wrote: post #31
ryanmarsh wrote: post #22

Earlier quoted context omitted.

Based upon momentum I believe the Electron based ecosystem has already won, yes. The momentum there eclipses... Eclipse, as well as many other closed and open source editors. If you don't see the Electron ecosystem as a winner today would you say they'll have won if all editors stay at their current momentum of new features and bug fixes?

How is it that text editors are all the sudden this weird competition where you have to win? I get what you're saying, but I think you worry too much about social proof and momentum. It's also grossly unfair to Xi, a project in its infancy. As you mentioned earlier, there is room for another great editor. If the same logic had been applied towards the Electron based editors a few years ago, you'd be arguing against t…

> How is it that text editors are all the sudden this weird competition where you have to win?

Editor holy wars [0] are not exactly new eh

[0] https://www.techfak.uni-bielefeld.de/~joern/jargon/holywars....

Re: Xi: an editor for the next 20 years [video]

#118

Post by Jyaif »

kazinator wrote: post #77
haberman wrote: post #59

Earlier quoted context omitted.

For the protocol between core and front-end, did you take any inspiration from mosh's state sync protocol? https://mosh.org/mosh-paper-draft.pdf

Text editors shouldn't have a "core" and "front end" and "protocol". Monolithic machine executable that fits into under a meg of RAM and comes up in a fraction of a second from a cold invocation.

I've got bad news for you: vim and the other editors you are thinking about also have a core (vim), front end (whatever terminal you use), and a protocol to talk in between them.

Re: Xi: an editor for the next 20 years [video]

#119

Post by c-smile »

raphlinus wrote: post #114
c-smile wrote: post #98

"Platform text rendering (CoreText, DirectWrite) not performant enough" That above needs some reliable proof to be honest. I am testing this claim with Sciter ( https://sciter.com )... On Windows Sciter uses Direct2D/DirectWrite (with an option to render on DirectX device directly) and/or Skia/OpenGL. On Mac it uses Skia/OpenGL with an option to use CoreGraphics. On Linux Cairo or Skia/OpenGL. Here is full screen tex…

I'll have to try this out. My experiments indicated that DirectWrite could not keep up with drawing on a 4k monitor at 60 Hz, though was ok at a smaller window. I think it might depend a lot on driver too. I'll see if I can instrument the xi-win prototype to give performance numbers. I do note that your lines aren't very wide, but still, in my tests I wasn't seeing anything like 500fps. DirectWrite does at least seem…

Let me know if you need more tests around this.

If to consider more complex DOM cases then you can try https://notes.sciter.com/ application. Or to run it from SDK directly: https://github.com/c-smile/sciter-sdk/blob/master/bin/32/not...

Notes window layout resembles IDE layout pretty close. And Notes works on Window, Mac and Linux so you can compare different native text rendering implementations (I mean without conventional browsers overhead).

Re: Xi: an editor for the next 20 years [video]

#120

Post by joshuak »

raphlinus wrote: post #11

Presenter here, feel free to ask questions. Also thanks to the awesome Recurse Center for inviting me to speak and making the recording, and the audience for their great questions.

Great work, and I'm looking forward to getting involved if I can. I'm just learning about this project, and am very interested as I'm doing a project with similar performance goals for filesystem navigation. It even has a CRDT based concurrency model, and a multi process architecture with back and front-end applications communicating across a JSON api.

I'm curious about your reasoning for JSON, as compared to protocol buffers, flat-buffers, etc. I would imagine that accessibility and ease of use would be the main reason for choosing JSON, is that in fact the case?

Are there any other reasons you chose JSON over other wire formats/protocols?

I agree with your assertion in the video that this is not much overhead, but I struggle with this debate as I work to scrape every ounce of performance out of the architecture.

Edit: Asked and answered elsewhere https://news.ycombinator.com/item?id=16268332

Post reply on HN