I have a requirement where a user's reaction time to a particular visual on the screen is recorded in milliseconds.  The time for the user reaction is measured in milliseconds so any kind of keyboard latency or keystate detection latency in XNA is of paramount importance for my game.

There seems to be some  lag in the accuracy of the determination of the user response time in milliseconds  when i run my XNA game.

I need some information on the time delay that might occur from the moment when user presses a key and the moment  it is detected from the

Keyboard.GetState()  from the update

My Update function is called 60 times a second and the keyboard input is read from there.

Apart from the  refresh time of 16.7 milliseconds  at which my update funtion is called is there an additional latency involved from the time the user presses the key and the time the input is detected in XNA?

Would this latency vary with different version of Windows? Would the latency also be dependent on the  hardware configuration of the machine?

How much would be the time between the moment the user presses the key on keyboard and the moment when XNA detects the keyboard event?

Any information regarding this would be greatly helpful and welcome.

Thanks.

Input latency can come from the hardware, the driver, the Windows message queue, and any delay before your next update call notices the change.  I don't have any data on what specific numbers you are likely to see here, but my guess is this can probably vary a fair amount on different hardware.

You should also be aware that there can be significant latency on graphical outputs, coming from a combination of deferred GPU render pipelines, page flipping, output signal encoding, signal decoding on the display device, any scaling or other processing that display device may apply, and finally the physical response latency of the screen itself.  Again this latency can vary significantly depending on the hardware.

If this is for a standalone experiment, I would recommend making a controlled test to measure the input and output latency on your particular hardware.

If you need it to work more widely, I think that's going to be tough.  XNA (in fact all of D3D and GPU hardware) is focused on 60hz animation, and not designed for either inputs or outputs with millisecond precision.

Yes, Thanks for the information .

However,  I would like to know if there is any delay apart from hardware .

Apart from hardware related delays , is there any delay that is introduced by XNA framework itself  for the detection of key event (Excluding the delay caused by the update itself) ?

Not that would be perceptible.

My application captures users responses in milliseconds so even a minor difference in milliseconds is of importance ; So iam curious to know the latency in milliseconds if any that is introduced by the XNA framework itself

Venkata Subramaniam:

My application captures users responses in milliseconds so even a minor difference in milliseconds is of importance ; So iam curious to know the latency in milliseconds if any that is introduced by the XNA framework itself

Any such added latency will depend on the hardware the software is running on.

Everything between your code and the user is not a real-time system, and you can not, therefore, expect real-time system style behaviour.

Trying to measure user responses on a millisecond level is real-time system style behaviour.

Venkata Subramaniam:

...  I would like to know if there is any delay apart from hardware ...
... I am curious to know the latency in milliseconds ...

I don't think anyone can give you a definitive answer.  We can all only guess.

Shawn was your best hope as he developed much of XNA and he has already answered with, no doubt, as much information as he has.

Neither Windows, nor XNA are designed for the type of input you are describing.  Windows apps are typically event driven but the keyboard is buffered and designed to avoid key bounces sending double characters so what you get timing wise is meaningless.  If I press the same key twice you may get the event twice but have to handle one before the other so your own code introduces latency.  If I repeat press the key too fast one of the presses will be ignored because it looks to the computer like a bounced key.

XNA is better because you have a loop usually of a known speed but it reads the state at a point in time.  If the end user is super fast they could press the keyboard multiple times between reading the state.

In the latter case you could try to get your Update() loop to be as often as you can (use the stopwatch class to measure it) and get the state of the keyboard as often as you can unrelated to how often you draw to the screen.  That still only captures as many keypresses as possible it does not tell you the real time the key was pressed.

I don't think you want to hear this but I think you need to look again at what you are trying to achieve and do it a different way.  Very accurate timing using a normal computer is a fallacy.

Regards

Venkata Subramaniam:

My application captures users responses in milliseconds so even a minor difference in milliseconds is of importance

I don't see how you can ever hope to time user responses with ms precision on a platform that is based on a 60hz game loop.

Also, I have a feeling that keyboard input latency may actually be the least of your concerns.  What are you measuring these inputs relative to?  If the trigger is graphical or audio output, those things are likely to have far more latency than any input mechanism you could choose.

In my application a stimulus is presented on the screen and the user has to respond as soon as the stimulus appears. My application records the time the stimulus is presented and the time the user responds to it by pressing the keyboard event. The time difference between the presentation of a stimulus and the user response is then calculated using a dotnet stop watch.

My application is an upgraded version of a scientific application developed in delphi. The two applications show a difference of more than 100 milliseconds for capturing the user responses ; so was just trying to find the latency of XNA framework for this particular case.

The trigger is a stimulus which is graphically presented on the screen.

To quote someone (JCBDigger?), above, "Neither Windows, nor XNA are designed for the type of input you are describing".

Venkata Subramaniam:

... in delphi. The two applications show a difference of more than 100 milliseconds for capturing the user responses...

I am surprised there is as much as 100ms difference.  That's a tenth of a second or 6 frames!

As far as I know you can't measure when something is drawn to the screen only when you have asked it to be drawn to the screen.  Most screens work at 60Hz so there is always a 16.67ms potential discrepancy between your timings.  It is likely to be consistent on a console but unpredictable on a massively multi-tasking windows PC.  Full screen mode would probably be most consistent.

I don't think anyone can answer your questions but if you manage to find or write some low level tool that can measure the difference between when the key is struck and when XNA first gets knowledge of it, then you should post the results here for others to see.

I for one assumed the Keyboard.GetState() function was real time.  I'm sure it makes no difference for games.

Regards

JCBDigger:

I for one assumed the Keyboard.GetState() function was real time.

I too believe that's the case.

But, whether it is or not is irrelevant - the problem here is that, at no point, can you guarentee that what you ask XNA to draw to screen will actually appear on the screen within a given amount of time (if at all)!

It's all down to those pesky elves again!

MY XNA game can run in fixed time step (60fps) or full variable timestep (300+fps). When I run in fixed time step, there is some noticeable input lag, at least in the mouse cursor. I'm assuming it's 1 frame, or about 17ms of lag. I might also be a couple frames of lag- hard to know, exactly.

If I run the game in full speed variable time step, the input lag is not perceptible.

Maybe try running as variable time step, using Game.IsFixedTimeStep set to false.

Just a thought, but you might be able to have a tight loop in a separate thread on a different processor that captures user input and timestamps it, avoiding draw latency altogether.  You can then compare that timestamp against a timestamp of when the stimulus was displayed.  Not something I've tried, but seems theoretically possible.