Live data from Hacker News

Typing inside of the default WSL terminal feels amazing (2018)

github.com

21–30 of 123 posts

Re: Typing inside of the default WSL terminal feels amazing (2018)

#21

Earlier quoted context omitted.

this one https://github.com/microsoft/terminal 30 seconds or so

This is about the classic conhost, not the new Windows Terminal.

the one that can't handle ctrl+c to cancel yes? lol

Re: Typing inside of the default WSL terminal feels amazing (2018)

#22
post #9

The surprising thing here is that this is the Ubuntu terminal. Indeed, each keystroke goes through the input driver, to USER32, through the console code, to the terminal process in question. But then it goes through a virtual input device, across the VM boundary (which, on Windows is a VM exit plus an entry), through the Linux input driver, into dash (or whatever Ubuntu uses these days), and then all the way back out…

Note that this content is one year old. At that point, WSL was not a virtual machine, it was Linux syscall emulation in the NT kernel.

Does that mean it's faster or slower now?

Re: Typing inside of the default WSL terminal feels amazing (2018)

#23
post #22

Earlier quoted context omitted.

Note that this content is one year old. At that point, WSL was not a virtual machine, it was Linux syscall emulation in the NT kernel.

Does that mean it's faster or slower now?

I would be shocked if it were faster.

Re: Typing inside of the default WSL terminal feels amazing (2018)

#24
post #22

Earlier quoted context omitted.

Note that this content is one year old. At that point, WSL was not a virtual machine, it was Linux syscall emulation in the NT kernel.

Does that mean it's faster or slower now?

WSL2 is generaly faster: https://news.ycombinator.com/item?id=19868282

Re: Typing inside of the default WSL terminal feels amazing (2018)

#27
post #9

The surprising thing here is that this is the Ubuntu terminal. Indeed, each keystroke goes through the input driver, to USER32, through the console code, to the terminal process in question. But then it goes through a virtual input device, across the VM boundary (which, on Windows is a VM exit plus an entry), through the Linux input driver, into dash (or whatever Ubuntu uses these days), and then all the way back out…

I think most of the latency between key press and rendering to screen is in the layout / drawing phase.

Forwarding a few function calls is usually pretty fast, the text layout and rendering part is what is slow. Especially since many UI frameworks don't render individual characters; you may end up redrawing a full line or more for every keystroke. (I only have experience with macOS / Cocoa rendering, and I was surprised how slow it is compared to all other things my code does)

Post reply on HN