I thought so, too. I'm not interested enough to benchmark it, but for all practical purposes it's instantaneous on my machine. As fast to open a new terminal as it is to switch to the existing one.
Mine takes 50ms, assuming wsl is hot (recorded screen and compared mouse click frame to window pop up frame). I think op should try a different wsl distro or a blank machine and compare differences. I have on access scanning off, performance on, Ubuntu wsl distro, and windows 10.
interesting side note, our brain is compensating for delay, it can do it to around 250ms
so if anything lags up to that amount our brain will compensate and make it feel imstantenious
there was interesting experiment that I reproduced at university, create app that slowly build up delay to clicks to allow brain to adapt, and then remove it completely.
result is that you have feeling that it reacts just before you actually click until brain adapts again to new timing
I don't think it's right to say that the compensation makes things feel instantaneous, but rather that we are able to still feel the association between input and result, allowing for coordinated feedback loops to be maintained. We do grow accustomed to the latency, but I do not think it is right to say that it feels like zero latency.
If the delay is long enough, the output does not just feel delayed, but entirely unrelated to the input.
A latency perception test involving a switch can easily be thrown off by a disconnect between the actual point of actuation vs. the end-users perceived point of actuation. For example, the user might feel - especially if exposed to a high system latency - that the switch actuation is after the button has physically bottomed out and squeezed with an increased force as if they were trying to mechanically induce the action, and later be surprised to realize that the actuation point was after less than half the key travel when the virtual latency is removed.
Without knowing the details of the experiment, I think this is a more likely explanation for a perception of negative latency: Not intuitively understanding the input trigger.
As a long time gamer, I can anecdotally corroborate your theory with my early experiences playing FPS games using a dial-up connection. Average ping was about 200ms which allowed for an enjoyable and accurate experience after some adjustment. >250ms was unpleasant and had a significant impact to ability.
It was for this reason that I, and many others, for a short period, got objectively "worse" at the game when we switched to ISDN/Cable and suddenly found ourselves with 20-30ms pings; Our brains were still including the compensating latency when firing.
This seems more like compensation for projectile velocity, no?
I am assuming that the latency is in enemy location due to the game running hitscan (instantaneous weapons without trajectory simulation) on the server. In this case, your aim is as when you clicked the trigger, but hit is only computed <latency> time later when the server processes the incoming shot request, at which point the enemy position has changed.
This makes the latency behave similar to projectile velocity, where you need to aim not where a target is but where a target will be. Changing to a setup with a lower latency would then be like using a much faster weapon which requires new training to use.
(Input latency would mean that if you move your aim and click the trigger, your aim would continue to change for <latency> time before the bullet fires towards whatever your aim ends up being. This is much worse.)
