Hacker News Reader

Comment by nickjj | Hacker News Reader

I like to see projects like this pop up because it's so easy to fall into a trap of accepting input latency that other more bloated UI frameworks bring.

As we all know, Electron is really bad in this department but it's not limited to Electron.

I recently installed native Linux and the problem exists there too. Gnome terminal has a MASSIVE amount of input latency compared to xterm. Even worse than the difference between Electron and any non-Electron app in Windows.

I wish more people embraced and went all-in with UI frameworks that were optimized for reduced latency. IMO reduced / low latency input is the most important feature for a terminal or code editor.

View on HN

Interesting, I definitely believe you after reading Dan Luu's posts a year or so ago on keyboard and terminal latency.

However I use mate terminal every day and it feels like it responds instantaneously, even over a USB keyboard connected to a dock connected to a laptop.

Maybe as long as the latency is below a certain threshold it is no longer noticeable.

It's a tricky thing to perceive because there's a lot of variables at play.

A lot of LCD monitors have 50-75ms of input lag. That means you don't even see what you type until 75ms afterwards so you might not even have a chance to see how a low latency application behaves. Then on top of that, there's the human factor. Some people are just more sensitive to this sort of thing.

The monitor I use happens to have about 13ms of input lag (verified with camera tests) which is pretty much as good as you can ask for with an IPS panel. I wrote all about picking monitors for programming at https://nickjanetakis.com/blog/how-to-pick-a-good-monitor-fo....

The difference is night and day when typing in an application that's not efficient vs one that is. Even typing in this comment box on HN feels like I'm typing in mud because Chrome's input lag is horrendous compared to xterm, WSL Ubuntu terminal or any other application that doesn't have a million layers of UI framework abstractions piled on.

If you're curious, one of the developers from the WSL Ubuntu terminal went into great detail on why their terminal is so fast. It's at https://github.com/Microsoft/console/issues/327.

The sad thing is, I've opened high input latency issues to a number of other terminals and the author of those terminals often come back saying "nah, your computer must be broken, otherwise everyone would be complaining" even after I supply them video proof. I guess that's what happens when you live in a world where everyone has low end monitors and are used to using Electron apps all day.

Yep my gear, especially the dock, probably enforces a minimum latency on everything.

The only time latency is noticeable to me is if I can type faster than displayed on screen. I type around 50 wpm so the computer doesn't have to respond that quickly to keep up. Online I found that equals 250 cpm, or ~4.2 cps, lets say it has 240ms per keypress to not fall behind. Plenty of time.

Your dock is a glorified USB hub, unless it's a more expensive Thunderbolt dock, in which case it's a glorified PCIe switch. In either case, the added latency is completely imperceptible to humans, and in the latter case, pretty hard to measure from userspace software. The dock is not even close to being the largest source of latency in the chain. The components that can be responsible for tens or hundreds of milliseconds of latency are the display, hard drives and overloaded SSDs, network, and bad software.

Yes, usb-c probably thunderbolt. Checked my dell external monitor, folks say they have a small lag. Don’t notice any difference between it and laptop monitor.

i recently purchased a monitor and was looking for a way to figure out input lag without a camera setup.

one recommendation was to test your reaction time [1] on a known low-latency display. mine old one was a 1080p 21.5" Dell IPS LCD. I was worried that a 2k or 4k display would introduce lag, though at 60hz anything within 16ms g2g will feel the same and the 1440p Viewsonic i got advertised 15ms.

Best reaction time (~190ms) over multiple trials did not change after switching to new display. Not scientific, but certainly enough to catch something as large as 20ms+.

[1] https://www.humanbenchmark.com/tests/reactiontime

For semi-new monitors you can find super in depth reviews at http://www.tftcentral.co.uk. They often include input lag. I highly recommend that site to get the true input lag of your monitor (without having to resort to your own tests).

g2g typically measures the response time of the monitor which is a different thing than input lag. Most manufacturers won't even list input lag on their specs even though it's one of the most important attributes of a monitor since it affects everything.

I could see the reaction time being a fun way to get an average with enough samples. I did 3 sets of 5 and it was 201, 194 and 196 as the average. But I think reaction time and being able to perceive input delay are different skill sets. I'm almost 40 so my reaction time sucks, but I can still notice a delay difference in apps when pressing a key.

The best way to measure end-to-end latency is an Arduino with a light sensor, with the Arduino programatically injecting USB events. I made an Amazon shopping list[1] a year ago. I hope to rework my code and post a blog soon.

[1] https://www.amazon.com/ideas/amzn1.account.AGSZP5AWBGH7772O3...

If you're into this sort of thing I recommend reading this article: http://www.tftcentral.co.uk/articles/input_lag.htm

It goes into a lot of depth on input lag and how to measure it accurately. The site also happens to have recorded input lag numbers for hundreds of monitors.

In the article it mentions using photo sensors and oscilloscopes as the best way to get a reading but they settle on using a special type of stopwatch test that gets results that are nearly the same.

I did such a thing a while ago at my last job. I guess it still works https://github.com/strawlab/lagtest

Agreed. For school I have to use Visual Studio on my laptop and the input lag is just absurd. (Surprisingly Code is pretty good.)

Yeah VSCode is pretty solid in this regard for an Electron app but I hope they continue to try and optimize it.

It's still very noticeably delayed compared to something like the default WSL terminal or xterm but VSCode has much lower key press latency than Hyper and a few other Electron terminals like Terminus.

They've re-written many performance sensitive components in C++. Thats why code performs really well. They've done a great job!

I think Atom has components in C++. VSCode is Javascript only.

oh yes sorry! I stand corrected.

The code performs really well because, as you say, they've done a great job engineering it. However, they've specifically stated a few cases where C++ wasn't pursued. An example: A while back I read a blog post [1] talking about how they analyzed why the text buffer was causing OOM errors for certain files. It's a really good read, discussing drawbacks of the initial array of lines data structure, and how they came to use the "piece tree" data structure, and some of the tradeoffs therein.

[1] https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...

I was astounded when I learned the VSCode was an electron app. I used it for almost 2 years without a clue. Very impressive.

This is for embedded development (e.g. a gui for your washing machine), not a replacement for Electron, Qt, GTK or what have you.

Yes, GuiLite could embeded in Qt, MFC... And you also could run without them, even without OS.

Reply on news.ycombinator.com