which shows Gvim on Windows with a maximum latency of 1.2ms - much faster than 30ms on the vintage Apple //e or TI 99/4. Even Eclipse, which usually feels slow to me, came in at a max of 20.8ms. (1.2ms seems very fast to me as I would expect ~2ms of average frame latency even on a 240Hz monitor?)
Which study is correct? Are both of them measuring touch-to-display latency?
It's also worth noting that those vintage 8-bit microcomputers typically used CRT TV monitors at 30Hz, while modern monitors often run at 60Hz or 120Hz or more (possibly with asynchronous refresh), so they will have lower frame latency.
While I haven't tested it myself, I believe newer iPad/Apple Pencil 2 combinations have improved their input latency (they claim 9ms but I'm not sure if that's actually end-to-end touch-to-display latency in something like Notes or Procreate.)
Dan Luu's post, which I also read months ago, is very detailed, has a lot of data, but fails to make sense or come to a helpful conclusion in the end. Like so many of his posts.
With helpful conclusion I don't mean just stating the facts or comparing transistors or input latency with network latency. As if developers stopped caring and created crappy software on purpose.
The post compares an Apple 2e, which is a single-tasking OS that just displays the pressed key in the basic interpreter on the screen, and modern devices, where it is not always clear, what kind of app or setup is being used. But we know, that it's plenty of layers of GUI and OS code, that most people don't want to miss. Not to mention, that mot of the higher input lag is not detectable by humans in normal work conditions.
Yes, there were years, were CPU performance couldn't keep up with added features, like immediate spell checking. I used computers through all those years and know this first-hand.
And I never dismissed the importance of input lag. I pointed out the oversimplification to support the main argument of the linked post, which suffers from this as a result.
> The post compares an Apple 2e, which is a single-tasking OS that just displays the pressed key in the basic interpreter on the screen, and modern devices, where it is not always clear, what kind of app or setup is being used. But we know, that it's plenty of layers of GUI and OS code, that most people don't want to miss. Not to mention, that mot of the higher input lag is not detectable by humans in normal work conditions.
You can do an experiment for yourself along these lines. A few years ago, I pulled out an old laptop that had Gnome 2.x installed as part of an Ubuntu release from circa 2009. In every respect, the hardware from this machine (which itself had been a budget laptop when it was purchased in 2006) was worse than the hardware I was using in my daily life. I was struck (almost startled), however, by the difference in how immediately it responded to my input compared to my daily driver at the time—to the point that it distracted me from the original reason I booted it up in the first place.
A system capable of running Gnome 2.x is no pre-Mac, pre-multitasking system. In fact, it has all the capabilities/affordances that you'd expect and need from systems today. So your characterization is less than kosher (basically a motte-and-bailey).
> But we know, that it's plenty of layers of GUI and OS code, that most people don't want to miss.
You're missing the main point: you're just assuming that we must trade those features for improved latency, but this is just not true. The properties he measured are a result of particular architectural and abstraction choices, but other choices could be made that don't necessarily require such sacrifices. For instance, the exokernel.
I'm not assuming that we must trade those features for improved latency. It is a possibility, but there are always alternatives.
Unfortunately in IT you always trade one set of problems for another. And clean architectures have to be watered down with time to stay practical.
Nobody is smart enough to predict all pros and cons accurately. We're always smarter after the fact. When we have finished a transition and gained some experience with the new technology. But then it's mostly too late to go back.
On top of that, computing is always a moving target. Now you have to target highly mobile devices with small batteries traveling at high speed in metal tubes connecting to unreliable networks. While more or less related to keyboard input lag, depending on where the action should be registered, you have to be careful where you spend your development resources.
That's why I think this is an oversimplification. True in its deepest form, but neglecting reality.
> Now you have to target highly mobile devices with small batteries traveling at high speed in metal tubes connecting to unreliable networks.
In another comment[1], I called your earlier characterization a motte-and-bailey[2]. I'd wager it was probably not deliberate in that case. I have to think, though, that you're at least aware of how intellectually dishonest this move is.
Compare like for like. The existence of my phone, running a completely different system and set of applications, has _no_ bearing on how responsive to input an entirely separate machine in a traditional laptop/desktop form factor is or explain why the state of things should have degraded over the last ~10–20 years.
I have recently seen ridiculously bad and slow smartphone apps, which seem to be so because they are programmed to phone home for every single action even though there is no need to do so.
https://pavelfatin.com/typing-with-pleasure/
which shows Gvim on Windows with a maximum latency of 1.2ms - much faster than 30ms on the vintage Apple //e or TI 99/4. Even Eclipse, which usually feels slow to me, came in at a max of 20.8ms. (1.2ms seems very fast to me as I would expect ~2ms of average frame latency even on a 240Hz monitor?)
Which study is correct? Are both of them measuring touch-to-display latency?
It's also worth noting that those vintage 8-bit microcomputers typically used CRT TV monitors at 30Hz, while modern monitors often run at 60Hz or 120Hz or more (possibly with asynchronous refresh), so they will have lower frame latency.
While I haven't tested it myself, I believe newer iPad/Apple Pencil 2 combinations have improved their input latency (they claim 9ms but I'm not sure if that's actually end-to-end touch-to-display latency in something like Notes or Procreate.)