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

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

github.com

Post reply on HN
Print view View original

41–50 of 123 posts

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

#41

Post by nickjj »

ahartmetz wrote: post #35
jakobegger wrote: post #27

Earlier quoted context omitted.

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 surpri…

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…

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...

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.

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

#42

Post by [deleted] »

ChrisSD wrote: post #34
rb808 wrote: post #28

Earlier quoted context omitted.

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

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?

[deleted]

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

#43

Post by pjc50 »

ahartmetz wrote: post #35
jakobegger wrote: post #27

Earlier quoted context omitted.

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 surpri…

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…

One frame of latency is not gratuitous; it's perfectly reasonable to not draw directly "ahead of the beam" and instead double-buffer. Otherwise you get a lot of tearing.

I very much doubt the console is watching vsync either.

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

#44

Post by 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.

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

#45

Post by acdha »

If anyone else is curious about measuring things like this, try the 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.

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

#46

Post by rb808 »

ChrisSD wrote: post #34
rb808 wrote: post #28

Earlier quoted context omitted.

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

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?

My org is a battleship lol.

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

#47

Post by 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.

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

#48

Post by ahartmetz »

pjc50 wrote: post #43
ahartmetz wrote: post #35

Earlier quoted context omitted.

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…

One frame of latency is not gratuitous; it's perfectly reasonable to not draw directly "ahead of the beam" and instead double-buffer. Otherwise you get a lot of tearing. I very much doubt the console is watching vsync either.

The extra frame that I mean is: console renders, vsync, compositor grabs it and renders, vsync. That is what happens on X11 with compositing AFAIK. Only one frame time / one vsync is really required before you consider specifics of the software involved. I've read somewhere that Windows also has an extra frame of latency for similar reasons as X11.

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

#49

Post by m0xte »

ohthehugemanate wrote: post #33
swiley wrote: post #23

Earlier quoted context omitted.

I would be shocked if it were faster.

Depends on the operation in question. Direct syscalls should be faster, but there are some big differences between the NT and Linux kernels. You end up getting all the poor performance areas of BOTH. That, and HyperV has an extremely fast lightweight VM mode for particular hardware. For example, running containers on HyperV actually runs them with VM level isolation, a la Kata containers... and at competitive speeds.…

Also if it touches NTFS you end up with MFT contention on small files which really knackers performance on WSL 1.

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

#50

Post by thaumasiotes »

nickjj wrote: post #41
ahartmetz wrote: post #35

Earlier quoted context omitted.

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…

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…

> 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.

Post reply on HN