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 just tremendously sad. I'd forgotten what instant feedback felt like.

You just can't get that responsiveness anymore.

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.

I started on the Apple II and i'ts been downhill since then. If I remember correctly the Apple II has one of the smallest latency between touching a key and seeing the result on the screen.

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.

So for a given set of timings, you'd always expect the CRT to be faster, because it represents the absolute minimum time-of-flight delay, assuming it is driven by a direct RAMDAC and not by a conversion box buffering an entire frame or significant portions.

Also, you can "move" electron beams at extremely high speeds. Even in a magnetic deflection CRT like the GDM-FW900 the electron beam can move at more than 80 km/s[1]. In some electrostatic deflection systems the speed of light is exceeded: they can draw a dot moving across the face of the CRT that moves at a higher speed than c. This is possible because "the beam" is a fictional object.

[1] 2304 dots across 482 mm with a pixel clock of around 384 MHz means these 2304 dots are covered in about 6 µs; 482 mm/6 µs = 80.3 km/s.

https://www.reddit.com/r/smashbros/wiki/lag

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

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 be no way to reliably focus the password field, and for whatever insane reason it's not just always in focus

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.

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.

Thanks for the AHK tip. The programs I usually find look like hastily-constructed malware on a dodgy sourceforge link & always make me feel real :-| about installing them on a fresh box.

Wow, how the time flies!

It's just glaringly obvious that nobody has bothered for even a second to think about how to solve the problem (or indeed, just copied the solution that already exists elsewhere).

The start menu on the other hand I gave up on several years ago. I don't know what's in it anymore, and I don't care, because nothing could be worth the >5s wait for it to open.

I don't use them.

I use Open-Shell (formerly Classic Shell). Before that I used Launchy (which is another crazy-fast alternative) tied to my CapsLock key.

I've also had tabs on my file Explorer windows, since Win 7 (thanks to QTTabBars). I'm commonly asked about that after I give remote desktop presentations.

If you try running a screen reader, such as Narrator (built into Windows; edit: turn it on and off with Ctrl+Win+Enter, even on the logon screen), you should find that even if the focus somehow gets away from the Password field, you can get back there with the help of speech output. Logging in blind doesn't have to mean logging in with no means of orientation.

(Disclosure: I'm a developer at Microsoft on the Windows accessibility team, working on Narrator among other things.)

The reason it works like this is that the user is forced to use the software. It should be the other way around. If people are forced to use something developers should do what they can to not make the experience incredibly annoying.

Sure, there can be situations where you need to cut corners but this is the log in screen.

After logging in I mistype an application name in the search box and wait for the dialog to pop up that says "Best matches" with an empty list under it. It can't even find "tunderbird"

If I type a single letter it shows "search teh web for "a".

But it does show Atom! Woah! Technology at work!

I get to chose, I can press the down arrow and select "apps" then press enter twice OR I can press the down arrow twice and press enter! Becareful! Dont press the arrow to fast or it jumps back to searching the web for "a".

No one put any thought into this process.

You're making an uncharitable assumption about real people who work full-time on this stuff. I can assure you that they do put a lot of thought into their work. No, I never worked on the Start menu or search myself, but before we started working from home, I was in the same building with the folks that do.

(The older versions of Windows had a native dialog box: http://www.guidebookgallery.org/pics/gui/startupshutdown/log... )

I like the UI simplicity of VSCode in contrast to native editors such as IntelliJ and Visual Studio, which I do use when I really need the features. I am interested in efforts like Onivim 2, which seek to combine these advantages.

For me at least.

I've found that I get perfectly passable syntax highlighting with vim, and haven't needed anything else on my current install. If I did use an editor other than vim, I would probably use VSCodium because open build, and I do really like the visual style.

The latest was I typed

    ...nameOfArrayInOtherFile

    import nameOfArrayInOtherFile from './tests/name-of-array-in-other-file.js';

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.

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.

I was curious so I did some tests:

https://imgur.com/a/73coWRR

It is on par with "the fastest terminal emulator in existence". :)

Scroll a bit down for Windows with power saving, Linux (section 3.4), and VirtualBox (3.5).

Newer tools only come as alternatives to faster tools that continue to be usable at any time.

For instance I choose to use VSCode and consciously weight it down with plugins and extra linters, because the trade-off is fine for me.

But I know vim is only a click away, and if I wanted sheer speed I’d do it there. And I actually do use it on a day to day basis, it’s just not my primary editor.

That, plus the ability to rejoin a session even from a different IP, makes working over SSH doable even from airplane Wi-Fi.

[0] https://mosh.org/

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.