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

91–100 of 104 posts

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

#91

Post by stinos »

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…

Also most LCD monitors do not update all pixels at once. So the topleft pixels effectively change about a frame earlier than the ones at the borrom right. Which puts some of the numbers there also into perspective.

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

#92

Post by throw_away »

modeless wrote: post #60
contravariant wrote: post #10

Earlier quoted context omitted.

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…

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.

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.

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

#93

Post by 29athrowaway »

fxtentacle wrote: post #75
coronadisaster wrote: post #43

Earlier quoted context omitted.

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

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

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

#94

Post by ponker »

modeless wrote: post #60
contravariant wrote: post #10

Earlier quoted context omitted.

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…

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.

Don’t think this is available on Windows 10 Home.

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

#95

Post by lukevp »

nwallin wrote: post #58
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.

It's not so much that CRTs are faster than LCD. It's that old consoles (up until the Sega Saturn, Nintendo 64, Sony Playstation era) didn't draw to frame buffers. They didn't have enough RAM to have a real frame buffer. You configured the graphics chip what you wanted it to draw, and as the scanline scanned across the screen, it outputted the color that was supposed to be output depending on the background/sprite/pal…

While this is true of LCDs, OLEDs have basically no draw latency, so conceivably they could directly update as the frame buffer was populating like a CRT if the gpu driver and OLED driver allowed it. This would still have tearing though for a modern game, so it is likely that it would need to buffer and draw entire frames at a time, which could still give you only 1 frame of latency. Most of the older games were not updating the positional information of sprites between frames (just using scanlines for raster effects) so there was already 1 frame of latency on input updates.

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

#96

Post by TeMPOraL »

throw_away wrote: post #92
modeless wrote: post #60

Earlier quoted context omitted.

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.

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.

> 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.

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

#97

Post by modeless »

ponker wrote: post #94
modeless wrote: post #60

Earlier quoted context omitted.

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.

Don’t think this is available on Windows 10 Home.

It might be possible to toggle this on Home using regedit if you can find the registry key that this UI controls.

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

#98

Post by formerly_proven »

kevingadd wrote: post #86
formerly_proven wrote: post #7

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

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…

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.

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

#99

Post by nwallin »

ponker wrote: post #83
nwallin wrote: post #58

Earlier quoted context omitted.

It's not so much that CRTs are faster than LCD. It's that old consoles (up until the Sega Saturn, Nintendo 64, Sony Playstation era) didn't draw to frame buffers. They didn't have enough RAM to have a real frame buffer. You configured the graphics chip what you wanted it to draw, and as the scanline scanned across the screen, it outputted the color that was supposed to be output depending on the background/sprite/pal…

Does n64 have a frame buffer?

Yes.

The N64 had a unified memory architecture, so the frame buffer was just a region of memory within the unified system RAM that was drawn to. The Z buffer was the same way. (assuming the programmer chose to enable to the Z buffer) It was still a frame buffer though.

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

#100

Post by Ballas »

dsissitka wrote: post #81
comfymatrix wrote: post #76

Earlier quoted context omitted.

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

Hm, maybe I'm overlooking something but I'm not sure that it is? In my tests Visual Studio Code averaged 31.7 ms and Emacs averaged 4.8 ms. It is on par with "the fastest terminal emulator in existence". :)

Your display pipeline has more latency than 31.7ms...
Post reply on HN