Input lag AB test

[spacediver]

good concept but I think this kind of test is made much much much more difficult by the fact that fluctuations in performance quickly overshadow the effects of input lag. there are also factors like how performance will increase initially as one becomes more experienced, and decreases or plateaus as one becomes fatigued. there's also the issue that one can be accustomed to small amounts of input lag and regain some of the performance lost. but that can be prevented by randomly switching the lag on and off between trials and keeping each trial short

I'll think about this some more and see if I can find methods that mitigate these complications

I deal with this on a daily basis! There are ways to overcome these problems, such as using multiple trials per condition, and randomizing the order of "presentation" to avoid order effects such as fatigue and learning effects.

[spacediver]

another thing that I was wondering about - the position of the cursor can only be displayed at discrete time points. So how are you able to add input lag at a finer precision than that afforded by the refresh of the display?

[flood]

another thing that I was wondering about - the position of the cursor can only be displayed at discrete time points. So how are you able to add input lag at a finer precision than that afforded by the refresh of the display?

the program itself runs with framerate much higher than refresh rate (no vsync). it stores a buffer of the history of mouse positions. during each frame, the history is updated, so the maximum precision is limited by either the mouse refresh rate or the framerate. for my setup, these are both 500hz.

okay well yea the absolute input lag is limited by the display refresh rate but the relative input lag, which is what the program controls, can be tuned more precisely.

[spacediver]

understood (I think), but the only way the user will feel any change in input lag is through rendered cursor position on the screen, and isn't that limited by the display refresh?


Suppose you have a system at 10 hz.

You initiate the movement of the mouse at the start of a new refresh. (t = 0 ms)

The cursor will visually respond at t = 100 ms (assuming no other source of lag).

Now repeat the experiment, but use your program to create input lag of 30 ms.

You initiate the movement of the mouse at the start of a new frame (t = 0 ms).

Software adds 30 ms of "artificial" lag.

The cursor can only respond at t = 100 ms, or t = 200 ms. It can't respond at t = 30 ms.

[flood]

suppose that the mouse can move from one position to another instantaneously at time x. think step function; at t < x the mouse is at point A and at t >= x the mouse is at point B

let's only consider the top of the screen

define the time origin such that the top of the screen refreshes at t=0ms, 100ms, 200ms, etc...

When there is no "artificial" input lag, then the time one sees the update is 100*ceil(x/100). so if x = 70ms or 90ms, the display shows the new position at t = 100ms. if x = 110ms, the display shows the new position at t = 200ms.

Now when there is 25ms of additional input lag, the time one sees the update is 100*ceil(x+25/100). so now, if x = 70ms, the display shows the new position at 100ms. BUT if x = 90ms, 90+25 = 115 so the display shows the new position at 200ms.

that is how a relative input lag shorter than the display refresh rate could potentially be detectable.


this "artificial" input lag should be exactly the same as real input lag (for example if your mouse cable were 10000000 meters long)

[spacediver]

Now when there is 25ms of additional input lag, the time one sees the update is 100*ceil(x+25/100). so now, if x = 70ms, the display shows the new position at 100ms. BUT if x = 90ms, 90+25 = 115 so the display shows the new position at 200ms.

that is how a relative input lag shorter than the display refresh rate could potentially be detectable.

I think I understand. Let me test my understanding:

(for the following, I'm considering visual feedback to occur only when the user accelerates the mouse - i.e. the initiation of a mouse movement, a change in direction, or a change in speed. Also assume a 10 hz display).

Without any artificial input lag, and assuming no input lag (other than the refresh lag), there will be a distribution of experienced lag that ranges from 0ms to (just under) 100 ms, and for any given feedback event, the exact value depends on where in the refresh cycle the user initiated an acceleration. We can assume the distribution will be uniform, and the mean experienced lag is 50 ms.

With an artificial input lag of, say, 25 ms, the distribution of lag will now range from 25 ms (if user initiates event just under 75 ms into a refresh cycle), to 125 ms (if user initiates event just over 75 ms into a refresh cycle). Again, the distribution will be uniform, but now the mean experienced lag is 75 ms).

Have I got this right?

this "artificial" input lag should be exactly the same as real input lag (for example if your mouse cable were 10000000 meters long)

Not sure what you mean here. The artificial input lag should be the same as real input lag, in order for what to happen?

[flood]

yup exactly.

Not sure what you mean here. The artificial input lag should be the same as real input lag, in order for what to happen?

well for the results of this test to be generalizable to things like driver input lag. eh it was kind of a tangential remark.

[spacediver]

awesome, thanks for your patience

Given that this is a "statistical effect", you need more data to be able to feel anything, especially with lower refresh rates.

I'm gonna try this at 140 hz, and see if it's easier to detect smaller input lag values.

edit: seems to revert to 75 hz when I run the program. Any way to have it adopt the desktop resolution/refresh?

[spacediver]

also, one other thing that people should understand when interpreting these results.

Our sensitivity to input lag may change depending upon the "pedestal" lag value. For example, if we are able to detect a lag of 12 ms relative to 0 ms, that doesn't necessarily mean we'll be able to detect 24 ms relative to 12 ms. With some phenomena, such as sensitivity to luminance, we become less sensitive as the pedestal luminance increases. With other phenomena, for example some forms of shape difference detection, we have a sweet spot where we're very sensitive to changes at certain pedestal values. Many phenomena show a weber law relationship, where we're sensitive to the proportional, rather than absolute, change in the underlying stimulus change.

What this means is that if one person were to run this program on systems that have a different amount of "pedestal" input lag, they might well get different results.

[flood]

edit: seems to revert to 75 hz when I run the program. Any way to have it adopt the desktop resolution/refresh?

hm love2d doesn't seem to be flexible enough to set refresh rate.

try changing nvidia 3d settings to prefer maximum refresh rate

or just create a non-standard custom resolution in nvidia for which there are no other refresh rates (like 960x600)

if nothing else works, try using the custom res util.