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

Typometer: A tool to measure and analyze the visual latency of text editors

pavelfatin.com

Post reply on HN
Print view View original

71–80 of 104 posts

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#71

Post by fxtentacle »

cjsawyer wrote: post #48
dahfizz wrote: post #32

Earlier quoted context omitted.

It really amazing playing with old technology. In Super Mario Bros on the NES, when you press the jump button Mario jumps the very next frame. And with a CRT you get instant response time. You just can't get that responsiveness anymore.

How does that compare to 144hz 1ms response gaming monitors? I know that late CRT’s handily beat early flatscreens but does that still hold?

For a PC, you'll most likely have USB latency, double-buffering, latency between the graphics card and the screen, latency due to picture processing in the screen. All that is additional to the 1ms that the pixels need to switch color after the instruction to do so has been received.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#73

Post by haecceity »

kirse wrote: post #18
PragmaticPulp wrote: post #11

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

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…

That might be slow because of autocomplete list starting and not because of rendering.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#74

Post by mrob »

ce4 wrote: post #47
yjftsjthsd-h wrote: post #45

Earlier quoted context omitted.

Wait, why would a CRT be faster than LCD? If anything, I'd naively expect faster response with no electron beam to move.

The NES-CRT connection is analog and the screen is drawn line by line, if you connect a digital monitor that will have to be buffered and you get some delay/lag of min 1 frame.

Most LCDs only buffer a single line at a time:

https://www.youtube.com/watch?v=wts8f1bNnbo

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#75

Post by fxtentacle »

coronadisaster wrote: post #43
29athrowaway wrote: post #34

Using Java to measure latency... Does not sound very accurate.

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

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.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#76

Post by comfymatrix »

dsissitka wrote: post #29
userbinator wrote: post #2

The companion article at 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 devel…

> I wonder how VSCode compares. I was curious so I did some tests: https://imgur.com/a/73coWRR

Thanks for this. I definitely wasn’t expecting VSCode to be almost on par with Emacs...

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#77

Post by fxtentacle »

userbinator wrote: post #2

The companion article at 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 devel…

I would say the big outlier here are the JetBrains IDEs like IntelliJ, which have had zero-latency as their default configuration for 2 years now.

Also, it is worth noting, that the same person doing this research is the one working for JetBrains on optimizing editor latency: https://blog.jetbrains.com/clion/2017/01/clion-starts-2017-1...

So there are companies taking the editor latency issue seriously and that are close to fixing it.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#78

Post by Kuinox »

yjftsjthsd-h wrote: post #45
dahfizz wrote: post #32

Earlier quoted context omitted.

It really amazing playing with old technology. In Super Mario Bros on the NES, when you press the jump button Mario jumps the very next frame. And with a CRT you get instant response time. You just can't get that responsiveness anymore.

Wait, why would a CRT be faster than LCD? If anything, I'd naively expect faster response with no electron beam to move.

CRT have latency in the nanosecond. Best LCD screen says they have 1ms latency.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#79

Post by mrob »

PragmaticPulp wrote: post #14
RcouF1uZ4gsC wrote: post #12

Earlier quoted context omitted.

>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 That is looking at the average latency for Atom. If you look at the max latency Atom, it is 60ms compared to 15 ms for Sublime text. That is basically 3 frames of latency difference on a 60Hz monitor, and would definitely be notable for t…

> That is basically 3 frames of latency difference on a 60Hz monitor, and would definitely be notable for the average person. Having done some UX work in this area, I can say that people greatly overestimate the effects of latency on text entry when they're just looking at the numbers. End-to-end lag is more obvious in situations like dragging objects, but even then people manage to work around it. Typing isn't perfo…

I use 60Hz keyboard autorepeat for navigation, so latency is very noticeable. I need prompt visual feedback to tell me if my estimate of the autorepeat startup delay is too short or too long. The quicker I get it the shorter the navigation sequence I can make while still having a good chance of hitting the correct frame-perfect key-release timing. Note that reaction time is irrelevant; I anticipate everything and only use the visual feedback for timing adjustment ("rushing or dragging" in drumming terminology).

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#80

Post by twoleftfeets »

tkzed49 wrote: post #5
userbinator wrote: post #2

The companion article at 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 devel…

I actually don't think that developers who use things like VSCode are simply naive. Personally, I am a young person and I frequently do use vim in a low-latency terminal emulator (xterm, mlterm) without a compositor. Yes, I enjoy the fact that it is very fast. However, I still use VSCode when I'm making more complicated edits primarily because of the plugin ecosystem. Plugins "just work", are easy to configure, and a…

Agreed. I've been editing since the late 70s. At the moment I use VSCode the most. The plugins are the thing. They are doing things I've seen no other editor do. Of course I haven't used every editor.

The latest was I typed

    ...nameOfArrayInOtherFile
and it auto inserted

    import nameOfArrayInOtherFile from './tests/name-of-array-in-other-file.js';
a few lines above some how recognizing the pattern.

Another thing I've seen VSCode do is give me library specific warnings. Maybe that's common now-a-days in other editors but I hadn't seen it before. I'd seen language warnings but not library warnings.

Post reply on HN