
Typometer: A tool to measure and analyze the visual latency of text editors - mrzool
https://pavelfatin.com/typometer/
======
userbinator
The companion article at [https://pavelfatin.com/typing-with-
pleasure/](https://pavelfatin.com/typing-with-pleasure/) has some example
results, showing Atom, the only Electron-based one in the list, as having
several times more latency than the others. I wonder how VSCode compares.

It's unfortunate that software seems to feel slower the newer it is, including
developer tools such as text editors/IDEs. I suspect this is because most
people - including younger developers - have never seen how fast things can
be, but are instead constantly subjected to delays in using applications to
the extent that they think it is an absolutely normal speed[1], and then
propagate that notion to the software they themselves create.

Also related: [https://danluu.com/input-lag/](https://danluu.com/input-lag/)

[1] For example, everything that uses UWP in Windows. Someone who had only
ever used the Settings app in Windows 10, or (even worse) the Calculator,
might not realise how absurdly slow they are in comparison to the previous
versions' where they would open nearly instantaneously.

~~~
contravariant
I also can't be the only one annoyed by the input lag in the windows login
screen and start menu search. Somehow both of them seem to think it's fine to
just ignore keypresses for half a second before doing anything.

Annoyance aside I seriously worry about the accessibility of the windows lock
screen. Through a weird display setup I sometimes find myself trying to log in
blind and I just can't do it. There seems to be no way to reliably focus the
password field, and for whatever insane reason it's not just always in focus

~~~
modeless
This insanity is apparently intentional, but can be fixed for the lock screen
at least: Win+R->gpedit.msc->"Computer Configuration"->"Administrative
Templates"->"Control Panel"->"Personalization"->"Do not display the lock
screen"->Enabled

This poorly named option doesn't disable locking the screen, it just fixes it
to not eat your first few keystrokes when you start typing your password.

~~~
throw_away
This is one of the reasons why Windows drives me bonkers— all the interesting
settings seem to be locked in disused basement lavatories. See also changing
capslock to control.

~~~
TeMPOraL
> _See also changing capslock to control._

Is it even possible to do it through system settings alone, even if obscure
ones? I use AutoHotkey to do Caps Lock -> Ctrl remap, and it's one of the
first programs I install on every new system.

~~~
kohtatsu
Happy 10th HN anniversary!

~~~
TeMPOraL
Thank you!

Wow, how the time flies!

------
formerly_proven
> Because sampling rate is fast enough to misinterpret contact bounce as
> keystrokes, keyboard control processor perform so-called debouncing of the
> signals by aggregating them across time to produce reliable output. Such a
> filtering introduces additional delay, which varies depending on
> microcontroller firmware. As manufacturers generally don’t disclose their
> firmware internals, let’s consider typical debouncing algorithms and assume
> that filtering adds ~7 ms delay, so that maximum total “debounce time” is
> about 12 ms, and average total debounce time is ~8.5 ms.

Debouncing in software is one of those things that 99 % of developers get
wrong, and is something even hardware manufacturers get wrong all the time.

A lot of hardware debounces in a dumb and naive way: On the first state
change, it waits 5-10 ms and sample the switch again to figure out if it was
pressed or not. So you get an inherent "debounce" delay, which is entirely
unnecessary.

Debouncing keys correctly works so: If the switch generates an edge, sent key
down/up event immediately and ignore further switch transitions for 5-10 ms.
_There is no point in waiting for the switch to surely have finished bouncing
before reporting the event, because if it is bouncing it MUST have been
pressed /released and you know which one it is because you know the prior
state of the switch_.

\---

Compositor delay due to VSync

Obviously compositors are using double-buffered vsync precisely because they
intend to limit FPS to $smallValue in order to save power and prevent the 3D
hardware from entering a high performance power state. They really _should_ be
using triple-buffered vsync, but only start to render if something changed,
resulting in much lower latency without constantly running at 1000 FPS. There
should be a way for the compositor to be notified of changes in client areas,
since stuff like X11 damage protocol and RDP are a thing.

~~~
kevingadd
Under normal circumstances Windows' DWM compositor will avoid compositing at
the display rate if nothing has changed. It used to be pretty easy to
demonstrate this by using a hook application (like fraps) to put a framerate
overlay on DWM, though I don't think that works anymore. If you have g-sync
enabled for the active windowed application, the DWM composition rate (and the
monitor scanout as a whole) will be tied to the windowed application's vsync,
so if it's running at 30hz so is your desktop until you tab away. Many G-Sync
monitors have a built in framerate overlay you can toggle on to observe this
(though the lag on your mouse cursor will make it obvious).

I suspect in practice most software is not very good at giving the compositor
the info it needs to avoid wasteful refreshes of the whole desktop, and the
compositor probably also isn't putting in as much effort as it could.

~~~
formerly_proven
That's a good point I totally forgot about. It actually means that most of the
infrastructure for this is already around and implemented, but of course
fundamentally this is an information problem - the compositor gets told when
applications "damaged" their output, but since there is no concept of
presenting a frame in these legacy 2D APIs (GDI/+, X11 etc.), the compositor
has no idea if the application will continuing "damaging" its output, or if it
is "done for now".

I think the best a compositor might be able to do is something along the lines
of keeping track of the latest possible time it has to start rendering such
that the frame can be swapped to the front and sent to the screen. This should
result in the lowest possible average latency while rendering at the vsync
rate. DWM is clearly not doing this (since the delay is discretized to 16.7/33
ms), the Linux might be doing this, or it might be rendering on every damage
event and use triple buffering, either would be plausibel given the 8 ms
average delay.

------
arexxbifs
Seeing as how this and similar articles regularly crop up here, I'm curious as
to when this started and why nothing is done about it. I still regularly use
my 14 MHz Amiga 1200 for recreational programming and I _never_ experience
input lag on that machine.

Thinking back, the first time I noticed input lag was on a Mac LCIII running
Word in the mid-90s. Then for a long long time I didn't come across any
particularly noticeable latency, except on really crappy websites and in
really crappy Java apps. Then Microsoft bought Skype and started working their
magic on it, and this seemed to open some kind of floodgate of high-latency
crap. That's not even a decade ago.

After that, little by little, everything seemed to slow down noticeably. We've
now reached a level when this is seemingly normal. Even programmer colleagues
who are my age and older are looking at me like I'm curious when I complain
about the latency. I'd say something toxic about Electron here, but it's
prevalent in native programs as well.

Have things really gotten so much more complex since 2010 that we can no
longer put a character on screen in a timely fashion?

~~~
jiggawatts
There are underlying reasons, much of which can be gathered under the umbrella
term of "virtualisation". Modern computers use layers upon layers of software
or hardware to present an interface pretending to each higher level that
things are simpler than they really are.

These abstractions, however, are leaky, and almost all of them are leaky in
the temporal sense. There's a pretend continuity or constant throughput that's
not really there.

Everyone knows that operating systems run short time slices of processes on
physical cores, so that each program can "pretend" that it runs continuously
on bare metal. But of course, _not really_ , so there are gaps in the flow of
execution that can occasionally be perceived by end-users.

If that were the only sin of pretense, then that could be worked around, or
carefully tuned, but the reality is that it's just one of many layers.

The garbage collector of managed languages (e.g.: JavaScript in Electron)
pauses execution within the process too.

Even unmanaged languages have variable overheads when allocating or de-
allocating from the shared heap.

The desktop window manager helps each application pretend that it has a
rectangular surface from (0,0) to (w,h), when in reality that is transformed
and overlaid. That can introduce a lot of variation, particularly because the
DWM has its _own_ threads and its _own_ garbage or heap.

The video card in turn is no longer just a block of memory mapped into the
address space of the program doing the drawing, but is its own little computer
with cores, threads, schedulers, locks, clocks, delays, and so forth.

The display in turn might further delay things because it has complex
overdrive or scaling logic, so it needs to buffer frames.

It's turtles all the way down.

~~~
arexxbifs
> Everyone knows that operating systems run short time slices of processes on
> physical cores

The Amiga 1200 I mentioned earlier does pre-emptive multitasking on a 14 MHz
CPU with 256 bytes of cache. I can switch between my IDE, my paint program,
the OS desktop, a file manager and a simple text editor without any noticeable
delay. It's as fast as flipping between desktops in FVWM on my PC (an
operation which, incidentally, never seems to suffer from latency).

> The video card in turn is no longer just a block of memory mapped into the
> address space of the program doing the drawing, but is its own little
> computer with cores, threads, schedulers, locks, clocks, delays, and so
> forth.

The graphics architecture of my Amiga consists of several different chips all
timed to a PAL signal and, since they're sharing memory with the CPU and other
I/O, are also affected by constant interrupts.

> The desktop window manager

There's a DWM on my Amiga as well, called Intuition, providing several
abstractions for programs to open screens and windows and render graphics and
text in them. Plus, of course, GadTools, the system library for drawing UI
widgets.

> The display in turn might further delay things because it has complex
> overdrive or scaling logic

The cheap, modern flatscreen connected to one of my Amigas upscales and
upsamples _and_ does A->D-conversion on the analog RGB signal and yet manages
to show my double-buffered displays scrolling in one pixel increments, with 50
Hz vsync without stuttering or tearing.

Yes, the layers of abstraction have increased in number and complexity, but so
has the speed of the surrounding architecture. My PC's clock speed is more
than 100 times that of the Amiga, it has 4000 times more RAM (in fact the
caches in my cheap CPU exceed the amount of RAM on the Amiga), displays are
now connected to the GPU with a wide-bandwith digital interface, and so on.

All of this could perhaps be valid excuses if it was consistent. Yet typing in
a Firefox <textarea> feels faster than typing in for example FocusWriter, and
typing in an xterm faster still. I can paint smooth freehand curves in Gimp
with instant feedback (something the Amiga is not always capable of, depending
on how much bandwidth the selected resolution requires). The computer is
capable of full screen, full frame, fully vsynced full HD movie playback
without stuttering or dropping frames.

The most interesting aspect is of course that a computer that might feel laggy
in certain applications is fully capable of emulating an Amiga, complete with
the perceived snappiness of the UI, despite all the overhead of emulation
_and_ the supposed delays of the surrounding architecture.

(edit: getting some numbers straight)

------
PragmaticPulp
I'm all for faster software, but input lag measurements need to be put in
perspective. Just because an editor can process an input in 3ms doesn't mean
the pixels will change on your screen in 3ms.

If you're using a 60Hz monitor, you're only going to see new frames every 17ms
at most (1 second / 60Hz). Your graphics pipeline might have some additional
buffering, adding 10s of milliseconds of lag. Your monitor likely has some
input processing as well, adding anywhere from 10-20ms before it sends the
frame to the physical display. Add a few milliseconds here and there for input
processing and even the response time of the physical pixels, and you're
looking at something like 50-60ms minimum for total display latency _before_
you factor in the software.

Using 144Hz FreeSync or G-Sync monitors can shorten that update time, but
you're still looking at 30ms end-to-end latency in even the fastest setups,
and that's before you account for software processing lag.

The difference between Sublime Text responding in 11.4ms average and Atom
responding in 28.4ms average is difference of almost exactly 1 frame of
latency for a typical 60Hz monitor. Add up all of the other sources of lag
(buffering, monitor input lag) and you're looking at something like a 5 frame
latency instead of a 4 frame latency. Still less than the blink of an eye
(literally).

From another perspective: If you really believe that you're sensitive enough
to feel a difference between something like Sublime Text's 11ms processing
latency vs. Atom's 28ms latency, then you might want to invest in a proper
144Hz gaming monitor with low input lag, as it would improve your experience
by the same margins. A gaming-specific keyboard might also help, as average
keyboards can have 10-20ms of input lag before the keypress registers with the
OS (Source: [https://pavelfatin.com/typing-with-
pleasure/](https://pavelfatin.com/typing-with-pleasure/) ) Realistically,
though, I doubt many people could A/B test the difference between a 1ms and a
30ms latency editor under ideal conditions, let alone while typing out some
code.

~~~
kirse
_If you really believe that you 're sensitive enough_

It's pretty obvious when using extended shortcuts or a string of keys that are
committed to muscle memory, like Ctrl+Shift+P (+ first letter of a cmd) or
Ctrl+K combos.

Imagine playing an instrument wired up to headphones and then adding a 30-60
ms delay... the longer the delay the more it creates that "off" feeling

Don't forget too, those are bare metal calculations. Stick those apps inside a
VM like many devs do or add some other latency along the I/O chain and it all
helps to create a perception of lag.

~~~
PragmaticPulp
> Imagine playing an instrument wired up to headphones and then adding a 30ms
> delay

We need to keep these numbers in context. 30ms delay would appear as an echo
if you were playing an instrument and also listening to a 30ms delayed version
of the same sound.

However, you're not feeling the _latency_. You're noticing the presence of two
distinct signals. That's why UX input latency matters much more when you're
doing something like dragging across the screen with your finger on the
screen: You visually register the distance between your finger and the
expected location.

However, when you're typing a memorized series of letters on a keyboard,
you're not comparing the keypresses to the letters appearing on the screen.
You already know what you're typing and what you expect to see on the screen.
Visual stimulus latency is on the order of 250ms, so you wouldn't even begin
to start processing types for an order of magnitude larger than the latency of
these text editors, for example.

Most of us are operating with regular 60Hz laptops or monitors. End-to-end
latency from physical key press to physical color change on your monitor might
be as high as 50-60ms even with zero-latency software.

~~~
jcelerier
> However, when you're typing a memorized series of letters on a keyboard,
> you're not comparing the keypresses to the letters appearing on the screen.
> You already know what you're typing and what you expect to see on the
> screen. Visual stimulus latency is on the order of 250ms, so you wouldn't
> even begin to start processing types for an order of magnitude larger than
> the latency of these text editors, for example.

nothing makes me want to throw my computer through the window faster than
typing and not having an instant response honestly. It doesn't matter that the
brain cannot process the letter. Would you imagine handwriting where the shape
of the letters you write is 1/4th of letter shape late ?

Even for typing, just comparing xterm at 60hz and 120hz on my monitor feels
different when typing moderately fast (100 wpm according to [https://typing-
speed-test.aoeu.eu/?lang=en](https://typing-speed-test.aoeu.eu/?lang=en))

------
vardump
Correct me if I'm wrong, but this doesn't seem to measure input stack latency
nor how long it takes for the pixels to be actually visible on the display
after all of the compositing delays.

All this measures seems to be time from injected keyboard event until pixels
change on whatever bitmap/surface in memory. Message passing, in other words.

~~~
wtallis
That sounds like it's measuring almost exactly the portion of the end-to-end
latency that an application can actually do anything to reduce; the rest is in
hardware and drivers. So it would definitely be a useful measure, but cutting
this measured latency in half won't cut the entire end-to-end latency in half.

~~~
vardump
Application might be able to make choices about APIs that affect output
latency. Hardware swap chain (AKA multi-plane overlay) is going to be visible
on the screen at least one full vsync faster than something that's composited
on a frame buffer. In the best case, this measuring method wouldn't see any
difference in such case. In the worst case reading pixels from the screen
might even misleadingly measure worse due to triggering a corner case code
path in the window compositor.

Using an emulated legacy API (like Windows GDI) might yield a very low latency
score in this test, even though it might take much _longer_ to actually be
visible on the display.

------
fxtentacle
I would love to see XCode on that benchmark, as I regularly manage to out-type
it.

------
galaxyLogic
I've been working on a browser-based editor, and it feels slow. So does this
input-field on Hacker News website. Is it something about the browsers?

------
29athrowaway
Using Java to measure latency... Does not sound very accurate.

~~~
coronadisaster
either way, if your text editor editor lags, there must be a bigger problem...
or are we back in the 60s?

~~~
fxtentacle
It's called Electron and it shouldn't have been used for building desktop apps
in the first place. I presume it was built as an inside joke when people were
joking about web browsers becoming the new OS.

That said, it allows companies to use cheap web developers to build
(previously more pricey) desktop apps, so it's used everywhere now. It's good
enough to make money, but obviously using the wrong tool for the job will make
some aspects of the experience worse.

Since most consumers hate working with the buggy software on their computer
anyway, the loss for a company in making it slightly worse by introducing
delay is negligible.

~~~
29athrowaway
When you compare Winamp 2.x with Spotify, you realize how slow software is
today.

~~~
fxtentacle
When you compare Winamp2 with Deezer, you realize that you can add 800MB of
bloat to an MP3 player :( Most of it is just Electron, though.

