51–60 of 104 posts
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.
Earlier quoted context omitted.
>Your monitor likely has some input processing as well, adding anywhere from 10-20ms before it sends the frame to the physical display. This is more in the 1-2ms range, even for non-gaming devices.
Good G-Sync or FreeSync gaming monitors can get down to low single digit millisecond numbers, but the typical 60Hz non-gaming monitor or laptop display will be more in the 8ms-15ms range. Example: https://www.rtings.com/monitor/tests/inputs/input-lag (Scroll down to the non-gaming monitors) The gray-to-gray response time for the physical pixels is in the neighborhood of 2-4ms, so the additional latency comes from the…
Example of a 9 year old "office" monitor: https://www.prad.de/testberichte/test-monitor-dell-u2412m/6/...
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…
The worst is when I see someone using vim or Emacs over SSH. If you think Electron apps are bad, imagine adding a network round trip between every keystroke!
That, plus the ability to rejoin a session even from a different IP, makes working over SSH doable even from airplane Wi-Fi.
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…
I don't agree with this at all. If the software doesn't care to make keypresses responsive how does this philosophy translate to anything more complicated than reading and rendering the result of these keystrokes? The answer is pretty obvious if you try any of the slower editors pointed out in the article (or pretty much 90% of software written in the last decade). It doesn't take a person with sensory hypersensitivi…
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?
Using Java to measure latency... Does not sound very accurate.
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.
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/palette settings. You could change where the sprite is halfway across the scanline, and it might immediately, in the middle of drawing a scanline, output a different color. There was no delays anywhere in the system, only the propagation delay of electricity in wires and transistors. The various HW registers that controlled what and where the sprites were were connected via a small pile of non-clocked digital logic gates to a DAC to the analog output pins of the graphics chip, which was connected to the electron guns directly if you used component video or via a simple, no-latency analog circuit if you had composite video.
These days, you program the graphics card to draw what you want it to draw. Once you've programmed everything for it to draw, it draws that into the backbuffer. Once the current frame has been sent to the display, the backbuffer is swapped with the frontbuffer. When the next frame begin is sent to the display, your changes finally go out across the wire. Depending on the display (see especially motion adapting TV screens) there might be more delay. Then whatever changes you make are finally displayed on the screen.
It's kinda weird. Old video game consoles (up until the SNES and Genesis) had extremely low latency. And that's been gone for 25 years. Not only is it gone, but it will likely be gone forever- we don't even make the technology anymore to show the new generation what it was like. On the one hand, the new technology is "better"; there's no way to do today's advanced graphics without a deep drawing pipeline that outputs to a frame buffer. But it's also somehow worse. We can make it less bad with technology like 144Hz and Freesync, but the old era is gone.
Earlier quoted context omitted.
I think the latency becomes most problematic when it's inconsistent, and if you want to fix input errors, or move the cursor and then input something. I've experimented with video games with various amounts of display lag or dropped frames; nothing blinded or anything (although, setting up a blind test sounds fun), and there's clearly an increase in difficulty the farther you get between input and response. Writing c…
> I think the latency becomes most problematic when it's inconsistent Indeed! I don't have a problem using say a SSH console with 1 second lag. After a bit of initial cursing, it works just fine, I can write my code or edit conf files just fine. It's not as comfortable as writing at home, but it's not really a big deal. However if the lag is inconsistent, say due to packet drops, it's horrible. Even if the base laten…
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…
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.