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

Post by sgillen » Sun, Jul 26, 2020, 3:48 AM UTC

cyberbanjo wrote: post #21

vz8 wrote: post #8

Earlier quoted context omitted.

Gui Emacs via tramp+ssh is awesome. Terminal Emacs over ssh is, well, just like anything else in a terminal over ssh. Can't say I notice the latency unless the datacenter is on the other side of the country.

Isnt it the same if you use tramp in the terminal, assuming you are running emacs locally and tramping into the server to edit?

Post by wyattpeak » Sun, Jul 26, 2020, 3:51 AM UTC

contravariant wrote: post #10

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

Post by vardump » Sun, Jul 26, 2020, 4:04 AM UTC

wtallis wrote: post #41

vardump wrote: post #40

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.

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.

Post by cjsawyer » Sun, Jul 26, 2020, 4:06 AM UTC

dahfizz wrote: post #32

senkora wrote: post #16

Earlier quoted context omitted.

A few months ago I found my old GameBoy and played through part of "Kirby: Nightmare in Dreamland". I know its not the most well-known game, so the relevant detail is that it relies a lot on timing and quick movements. I was completely blown away by the responsiveness of the controls. The control feedback was instant , frames were rock-solid, and there were no loading screens at all. When I put down the game, I was j…

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.

Post by 6510 » Sun, Jul 26, 2020, 4:19 AM UTC

mwcampbell wrote: post #28

contravariant wrote: post #25

Earlier quoted context omitted.

Fair enough, but on a screen who's sole purpose is to let me type in my password I really shouldn't require a Narrator to find the one and only input field. It's nice that the problem has a solution, but it shouldn't have been a problem to begin with.

The trouble is that this screen isn't just for entering your password. On my logon screen, I have not only the PIN field (because I enabled the TPM-based Windows Hello feature), but also these other links or buttons: "I forgot my PIN", "Sign-in options", network, Ease of Access, and power. So use of a full GUI framework, that supports accessibility tools such as a screen reader, is justified.