
Typing inside of the default WSL terminal feels amazing (2018) - hnbreak
https://github.com/microsoft/terminal/issues/327
======
nickjj
Author of the GitHub issue here. I was surprised to see this title, because I
thought "holy cow, finally someone else appreciates low input latency" and
then I realized it was my issue haha.

By the way, wsltty 3.x also has excellent input latency now too. I've been
using it for quite a while now with terminal Vim in WSL and it's about 90% as
good as xterm on native Linux in terms of latency. wsltty also has no issues
with tmux where as the MS terminal (both old and new) have severe issues with
tmux.

~~~
bhauer
Thank you for providing the praise to the Windows Terminal team many of us
know they deserve, allowing us to just click the thumbs-up response on GitHub.

I truly wish more modern software were capable of reaching this level of
latency performance. I understand the response provided by "miniksa" at
GitHub, but I don't feel satisfied by it. The maintainers of the frameworks
that are described as adding so much latency should make a concerted effort to
minimize that latency. We know from experience (see ASP.NET Core) that huge
strides can be made in performance (both measured as throughput and latency)
and that it is massively rewarding. It requires effort, but the payoffs are
real.

I fear computer science is often encumbered by a corrosive culture of "good
enough" with respect to performance. We have a lot of baggage and urban myths
about performance, from maxims about optimization handed down from the first
acolytes of computer science, to modern opinions about UX that over-emphasize
simplicity, to a repertoire of clever psychological countermeasures for under-
performance such as animation. It's a shame that more people don't appreciate
how much more enjoyable computing is when latency is nearly zero.

Obviously orders of magnitude matter. The change from 1000ms to 100ms is more
significant than a change from 100ms to 10ms. But we cannot diminish that
latter change and we should not accept 100ms as good enough. Improving from
100ms to 10ms is still huge and some of us deeply appreciate it.

~~~
acdha
> I fear computer science is often encumbered by a corrosive culture of "good
> enough" with respect to performance. We have a lot of baggage and urban
> myths about performance, from maxims about optimization handed down from the
> first acolytes of computer science, to modern opinions about UX that over-
> emphasize simplicity, to a repertoire of clever psychological
> countermeasures for under-performance such as animation. It's a shame that
> more people don't appreciate how much more enjoyable computing is when
> latency is nearly zero.

I wouldn't blame this on computer science: it's really just a long way of
saying you get what you measure. It's not that computer scientists don't care
about performance, or that human factors / UX isn't an entire field, but
simply that most projects don't set performance goals or prioritize them and
unsurprisingly most time is spent on the things which are used to judge
someone's job performance.

This is especially true when you see how many issues are shared across teams —
in this case talking about Windows it's important to remember that during the
Ballmer lost years, Microsoft used stack ranking to force managers to
categorize a set fraction of people as low performances and reportedly those
rankings heavily favored new features over maintenance improvements. In an
environment like that, if the change requires coordination across teams it
probably just isn't going to happen unless someone very senior makes it a
business priority.

------
amluto
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 again, and _then_ it gets rendered.

The fact that this whole dance is faster than notepad.exe suggests that Linux
is doing pretty well, that MS’s hypervisor stack is performing well, and that
the fancier MS frameworks are really quite slow.

(To be fair, the GNOME Wayland stack has recently been upgraded from awful to
sort-of-decent latency-wise. It’s all too easy to design a system where
latency wasn’t a primary consideration from day 1 and to have a very hard time
improving latency after the fact.)

~~~
jakobegger
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)

~~~
ahartmetz
All of the actual work can easily happen in under a millisecond. What makes
input to screen output slow is anything asynchronous - polling (on the input
side, e.g. in the USB protocol itself - USB to PCI uses interrupts!) and
waiting for the next frame on the output side. Let's say the console waits for
vsync to render its next frame, then the compositor grabs it and renders it in
the next frame. That is one frame of gratuitous latency.

~~~
nickjj
Then there's also the input lag of your monitor too which is really important.

A lot of monitors have really bad input lag, in the 50-60ms range and it's
highly variable. This spec is also not usually listed by the manufacturer
either and it's not the same thing as response time which is typically 1-10ms
in most modern LCDs.

Your monitor's input lag plays a very big role in how fast key presses are
perceived because ultimately what makes something feel fast and snappy
requires an end to end measurement of you pressing a key and then your
eyeballs being able to register it.

The monitor I picked has about 10-14ms of input lag which is very good
compared to the average. That's running at 2560x1440 (60hz) at 1:1 scaling
too.

If anyone is interested in that sort of thing, a while back I put together a
very detailed post on picking a good monitor for software development at:
[https://nickjanetakis.com/blog/how-to-pick-a-good-monitor-
fo...](https://nickjanetakis.com/blog/how-to-pick-a-good-monitor-for-software-
development)

I still use the same monitor today and I would buy it again today if I were
thinking about upgrading. Although I kind of regret writing that blog post now
because the monitor is almost twice as expensive today as it was 3 years ago.

~~~
thaumasiotes
> Physical size doesn’t constitute how much you can fit on a monitor. For
> example my mom thinks that a 25” 1080p monitor is going to let her fit more
> things on her screen than a 22” 1080p monitor. Don’t be my mom!

> The only thing that matters for “fitting more stuff on the screen” is the
> resolution of the monitor.

This is only true under the assumption that your eyes have infinite
resolution. In the more likely case that they don't, the larger size of the
pixels at a higher physical screen size means you need fewer pixels, with the
result that you can indeed fit more stuff on the screen at the same
resolution.

~~~
ClumsyPilot
It's not just eye resolution, its how the application is designed. An older
WinForms application will have very compact ui and mad information density,
but some modern web apps will dedicate an entire 1080p window to display 1
icon and two buttons.

I would say that combined with DPI scaling, his port provides a reasonable
rule of thumb.

------
acdha
If anyone else is curious about measuring things like this, try the
[https://isitsnappy.com/](https://isitsnappy.com/) app on a modern phone.

It’s real nice to have some competition for macOS on this front — and
especially when it moves out of terminals into related tools like editors
(VSCode was close to Terminal.app the last time I measured while e.g. Atom was
fully an order of magnitude worse). This is a frictional productivity cost
which most people discount because it’s not as obvious.

------
skrebbel
I just tried it and I'm blown away and confused: why is Windows Terminal
faster in an ubuntu tab (WSL1, in my case) than in a cmd.exe / powershell tab?
I mean the exact same terminal window. Three tabs side by side. The ubuntu one
is instantaneous and the others have short but noticeable lag.

This really surprises me.

------
dmitriid
> Of course this also means that we have trade offs. We don't support fully
> international text like pretty much every other application will. RTL? No go
> zone right now. Surrogate pairs and emoji? We're getting there but not there
> yet. Indic scripts? Nope.

You could say that a longer version of that answer is "Text Rendering Hates
You": [https://gankra.github.io/blah/text-hates-
you/](https://gankra.github.io/blah/text-hates-you/)

------
mikekchar
I'm curious how alacritty compares to it. The alacritty devs basically
consider another terminal app rendering faster than them to be a bug on their
part ;-) But it _does_ sound like it would be a good challenge.

~~~
nickjj
Alacritty has kind of a lot of input latency, it's noticeably worse than
wsltty and the default WSL terminal -- at least back when I checked it a year
ago.

I think some work has been done to improve it, but at this point IMO if you're
on Windows then wsltty is as good as it gets for a general purpose terminal.
If you're on Linux, xterm is top notch.

~~~
est31
What's top notch on Wayland?

~~~
nickjj
I never used Wayland, sorry.

------
celeritascelery
> Of course this also means that we have trade offs. We don't support fully
> international text like pretty much every other application will. RTL? No go
> zone right now. Surrogate pairs and emoji? We're getting there but not there
> yet. Indic scripts? Nope.

I find it interesting that Even though I don’t care about any of the above
features, I still pay for them working with text in other applications. They
are a constant tax on latency. It would be great if applications had a “ascii”
mode and a “full” mode. You can take the performance or the features, but you
can’t have both.

~~~
cogman10
I could be wrong, but I think the payment for one pays for the others.
International text is one of those "a large portion of the world wants this"
sorts of features. Once you've gotten that, emojis sort of come along for the
ride.

~~~
cryptonector
Emojis add complexity that other scripts don't, mostly in the form of color
processing (all other scripts are monochrome!).

------
mrkeen
WSL terminal is garbage. Here's what irks me:

* I click on the icon and I get a terminal up (nevermind that it doesn't accept focus on startup, so I start typing and the characters keep going to my task bar).

* I type in "clear && ls" and hit enter.

* My line of text vanishes and I'm left with a completely black terminal. If I scroll up with the mouse-wheel I can see what I should have seen (the output of ls).

* I press up (to step backward through my command history) and all the text vanishes again.

The only workaround I have is to run something like tmux, which is somehow
smart enough to render the text on-screen.

~~~
cosmiccatnap
I agree, been trying to make this setup work for over a year now because I use
Windows at work for a few things here and there but it's just not worth it
really...

You would do much better to install Linux and virtualize windows, then you get
the best of both worlds. it's great that windows decided to add a terminal
after every other OS has had it for decades but I think this thread is a bit
like having rose colored glasses on top of your drunk goggles because WSL and
Windows terminal are still an ocean away from a usable low latency terminal
environment compared even to OS/2 if we're being brutally honest...

~~~
mtrower
Say _what_?

Exactly which release of Windows do you think _didn 't_ supply a terminal?

------
LeonM
I'm a heavy WSL user, ever since I switched to Windows last year (after using
MacOS for 6 years, and Linux before that).

I must agree that typing is pretty responsive compared to other windows
applications, but still nothing near the native experience. I also run clear
linux natively on my laptop, and typing in that terminal is just faster.

------
baybal2
Qt KTerm, and VTE both supported complex typographies close to 20 years ago
and nevertheless achieve similar performance.

It is a testament just how much behind times MS was up until recently.

~~~
mtrower
From my perspective though, libVTE performance is terrible. On modern systems
it may not be a concern, but on some of my older systems VTE terminals are
unusable for any significant throughput of text (while xterm and rxvt run like
greased lightning).

While I've never benchmarked them, the original NT console running on that
same old hardware feels roughly in the same class as xterm. Per the dev
response on the Issue, it sounds as though not too much has changed under the
hood. If adding support for such typographies would put it in the same
performance class as VTE, I'd consider that a serious regression (at least an
order of magnitude).

Or are you saying that the Windows terminal has already regressed that far?

------
dsego
This is great to see. My experience with windows in general is that the typing
latency is usually very bad compared to ubuntu. I can literally notice the
lag. Plus some apps have these awful typing animations which make typing feel
like wading through mud.

------
kgwxd
I didn't realize how bad input latency had gotten in general until recently
when I needed to boot directly into a terminal. Sometimes I could swear the
character appears on the screen before I even hit the key. It's a weird
feeling, but I would like more of it.

~~~
nickjj
I know the feeling.

A few months ago I was installing Debian on a desktop, and there's this one
part during the installer where it prompts you for some information before
your desktop is ready to go.

The input processing was so fast it was stupid. It somehow felt even faster
than xterm which is already so much better than just about any app on any OS.

------
jankotek
Long time ago we used RXVT because XTerm and ATerm were both too slow

~~~
bbmario
RXVT sucks, but typing on it feels so good that it is what I use.

------
TheFiend7
Correct me if I'm wrong but I've been struggling to really nail down my
development process of linux software on Windows, and based on my readings, a
lot of articles state that applications perform far better on traditional
hypervisors like VMWare and VirtualBox than WSL.

I mean it may be great that the WSL terminal feels good, but if my program
takes 2-5x slower in WSL for testing, I'm still going to opt for a hypervisor.

------
swah
Related [https://danluu.com/term-latency/](https://danluu.com/term-latency/)

------
big_chungus
I often find myself using cmd (the old terminal prompt that is default WSL) on
windows. It's not perfect, but I found a patch to enable ANSI color support
and it's so much better latency-wise. I hope others work as well in the
future; the fancy new much-lauded windows terminal, on the other hand, is to
horribly latent for comfortable use (as are many others).

------
dang
Discussed earlier this year:
[https://news.ycombinator.com/item?id=19471857](https://news.ycombinator.com/item?id=19471857)

I feel like there was a larger discussion too, but can't find it. Anyone?

------
z3t4
I really wish there was a way for the browser to blit pixels to the screen in
the shortest amount of time possible. Like talking directly to the GFX
hardware using a restricted API like the Canvas 2d context.

~~~
rwerkjlkjweq
That is literally what DirectX/Vulkan is for. They are the fastest API to blit
pixels to screen (surfaces/textures as they call it).

~~~
z3t4
I don't have high hopes for something designed by committee.

The Chromium team are experimenting with Low-latency (desynchronized) canvas,
although I haven't been able to measure any differences in latency, the only
difference is that desyncronization will cause some render issues.

I guess latency is a "full stack" problem where you have to design everything
with low latency in mind. eg. keyboard, keyboard driver, render framework, gfx
driver, and screen.

Here's an interesting article: [https://danluu.com/input-
lag/](https://danluu.com/input-lag/)

------
wirrbel
How I wish that I could use the new terminal app on the windows 10 build that
is installed on my work Laptop.

~~~
rb808
Wow your work laptop is up to 10 already? We've started to plan our migration.

~~~
ChrisSD
Windows 7.1 extend support ends on January 14, 2020. So is your org planning a
very fast rollout or is it paying $$$ for Extended Security Updates?

~~~
poizan42
There is nothing called Windows 7.1. Windows 7 extended support ends January
14, 2020. Windows 8.1 won't end its extended support until January 10, 2023.

~~~
snazz
It most likely is a reference to Windows 7 SP1. I've never seen it written as
"7.1" but that is probably what they meant.

~~~
ChrisSD
Yes sorry, that was a brain fart. I did indeed mean SP1. The Windows SDK
version is 7.1 so I got muddled.

Windows 7 (without SP1) is already unsupported.

------
verroq
Anyone else notice that typing directly on the tty is much faster than in a
terminal emulator in X11?

~~~
mtrower
Yes, without exception. It's less noticeable on today's powerful systems, but
it's still true. Text mode is just faster than graphics mode, at least on any
system where I've used both.

------
initself
Does Debian benefit from this work?

------
a2tech
TLDR (only slightly sarcastic); 'Because we do things the hard way instead of
buying into the 30 layers of abstraction hype'

------
poizan42
Can a mod add (2018) to the title?

~~~
dang
Done now!

------
asdfsf12323yc
lol, it crashes when output a lot of text try: yes

~~~
Narishma
I just did. It works fine. How long should I let it run?

~~~
asdfsf12323yc
this one
[https://github.com/microsoft/terminal](https://github.com/microsoft/terminal)

30 seconds or so

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

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

~~~
mkl
Ctrl-C works fine in WSL on the current/old console.

------
jeromescuggs
wsltty is the most underrated app i use on the regular. i was pumped about the
new microsoft terminal for all of 5 seconds, then i used it, what a letdown.

with alot of help from wsltty and autohotkey, i am quickly approaching some
sort of windows+linux singularity event,
[https://i.imgur.com/cXykxPN.png](https://i.imgur.com/cXykxPN.png)

~~~
1996
What apps are you using there?

------
birdyrooster
Too bad it doesn’t handle Unicode. Also it’s a shame that it doesn’t have tabs
or any hot keys for increasing productivity. It’s really a good shell if you
don’t have work to do.

~~~
nickjj
Yeah, that's why I switched to wsltty many many months ago. It has comparable
input latency, good hotkey support, clickable URLs, unicode support, etc..

~~~
birdyrooster
Thank you very much! I will try that out.

------
flowerlad
I was excited about WSL when I first heard about it. But that excitement
quickly faded when I realized most real apps, such as gcc, don't work under
it. The best way to get a Linux prompt on Windows is to use Docker. Use the -v
option to share your drive.

~~~
boston_sre87
Think it'd be worth trying on wsl2 again. The first version was too slow to
use, but I am loving wsl 2 now. The integration between windows and the wsl2
vm is a lot more seamless than it used to be. You can navigate the c drive
from the wsl shell and also do stuff like `explorer.exe .` to open a windows
folder app in the current wsl directory. The vscode integration is amazing as
well. After using a mac for many years, it took me about a week to be sold on
using a windows laptop from here on out.

------
lukeschlather
It's funny, because I quit using WSL because of high latency. I can't say
input latency is a big deal to me. I can always wait 100ms for the buffer to
catch up with my typing.

But when most commands have 500ms of overhead that is another story. My Xfce4
terminal running in a Hyper V VM is so much faster. If only there were
seamless copy-paste. (Incidentally, I tried using Virtualbox but the latency
there is more like WSL.)

~~~
nickjj
You could always run VcXsrv to act as an X server.

Then you can launch GUI apps through your Hyper-V based VM (or any
hypervisor).

It has seamless clipboard sharing that works out of the box once you enable
the option.

I even went as far as running i3wm through VcXsrv for a while but ultimately
gave that up since multi-monitor support didn't really work, but if you have 1
monitor it was actually quite usable.

