If gsync is enabled for windowed applications in the nvidia control panel it actually synchronizes to the active window not the rest of the OS. This can actually be pretty problematic if your not a single app at a time user which is why it defaults to turning on just fullscreen gsync when you toggle it.

Hardware acceleration or not probably doesn't play into it as much as how abstract are the layers i.e. are there 4 layers of hardware abstraction library to make the app work everywhere which use it's own buffering to stay smooth regardless of the underlaying system and then hands that to the OS which then buffers it as part of the compositor to be displayed or does something just blit "n" to the display framebuffer as the latter is likely to have less delay/jitter.

Comparing 'Chrome html input' to VS Code in the article, it seems like Chrome is capable of rendering typed text with low latency. This seems to imply that the high input latency in VS Code can't be due to low level GPU and rendering pipeline issues brought about by electron, and must instead be due to processing VS Code is itself doing every time you type (syntax highlighting, semantic things, layout?). If this is true it seems unlikely monitor refresh rate or gsync could help.

Chrome has effectively a 1 frame latency. First the event fires for a keypress, and later the compositor decides it's time for a new frame, which will include the effects of that keypress.

VScode has its own renderer for drawing code tabs and the sidebar components along with custom input handling, bypassing chrome engine, I believe. They're not webviews like extension tabs and are much faster.

Sorry, but that is just nonsense. VSCode is running on plain Electron in this case. There is no "bypasses chrome" magic going on here.

Try DOS w/ XT keyboard.

Amatuer. Any intterupt-based (at/xt/ps2) passive matrix keyboard, realtime kernel, and a CRT is the way of the low latency wizard.