Measure button to pixel full input lag

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
Q83Ia7ta
Posts: 761
Joined: 18 Dec 2013, 09:29

Measure button to pixel full input lag

Post by Q83Ia7ta » 09 Dec 2016, 08:55

Hello blurbusters!
In this thread I want to hear recommendations and help with getting best results of testing full input lag chain (from mouse button to monitor pixel) with different monitors.

My equipment currently is:
Mouse: Logitech G100S mouse with LED connected to right mouse button
Camera: Nikon 1 J1 that can capture 5 seconds video with 320x120 at 1200 fps
Software: ioquake3 1.36 (optimized Quake 3 engine) that shows 1000 fps
CPU & Motherboard: Intel Core i5-6600 at Gigabyte GA-H110M-DS2 DDR3
GPU: Asus GTX 950 STRIX-GTX950-DC2OC-2GD5-GAMING
OS: Windows 10 Enterprise LTSB 32-bit

Setup and method looks similar to this one http://www.blurbusters.com/gsync/preview2/

But I positioned camera far back to capture whole screen. Because frame update with VSYNC OFF can start at any part of screen. And I used showing of huge crosshair instead weapon fire.

Example: https://www.youtube.com/watch?v=hFpnim0N6zE

My results are:
eew.png
eew.png (24.66 KiB) Viewed 9064 times
As can you see I got too big diffence of several frames (4th column, milliseconds, max - min). That leads to wrong average values (1st column). I guess that can be caused by microlags of ioquake3 caused by too high fps value (sv_fps 1000 & com_maxfps 1000).

Can anybody help with writing code of simple fullscreen directx/opengl/vulkan app with raw mouse input to get better results?

User avatar
lexlazootin
Posts: 1251
Joined: 16 Dec 2014, 02:57

Re: Measure button to pixel full input lag

Post by lexlazootin » 09 Dec 2016, 11:34

As you might of seen Flood did a pretty dandy job of sending me his 16000fps dx application, but you might need it to be modified to work with mouse clicks on not mouse movement and to work with 32bit :?:

And as you might know your mouse click/debounce add quite a lot of the input lag, so to remove a big part of the variable you might wanna remove the mouse completely.

You have a pretty strange system there? 6600k with a 950? LTSB 32-bit?

Q83Ia7ta
Posts: 761
Joined: 18 Dec 2013, 09:29

Re: Measure button to pixel full input lag

Post by Q83Ia7ta » 09 Dec 2016, 12:52

lexlazootin wrote:As you might of seen Flood did a pretty dandy job of sending me his 16000fps dx application, but you might need it to be modified to work with mouse clicks on not mouse movement and to work with 32bit :?:
Just found it. Thanks!
lexlazootin wrote:And as you might know your mouse click/debounce add quite a lot of the input lag, so to remove a big part of the variable you might wanna remove the mouse completely.
Logitech G100S has have quite low button lag by different tests. This is example:
http://cdn.overclock.net/8/8e/8e56a60d_ ... 150718.png
May be it sound stupid buy why I need debounce? Right mouse button binds to enable crosshair. Left mouse button binds to disable crosshair.
lexlazootin wrote:You have a pretty strange system there? 6600k with a 950? LTSB 32-bit?
i5-6600 not K :)
I need GTX 950 for DisplayPort and my main "game" delivers 250fps without problems :)
LTSB is beacause that OS is for gaming with less background tasks. I don't need Cortana, Store, Edge, etc there. 32-bit for less overhead if it exist. Will jump to 64-bit soon to compare.

Soon I will try to measure BenQ XL2540 but with a such variance (dispersion) like now it will be almost useless.

User avatar
lexlazootin
Posts: 1251
Joined: 16 Dec 2014, 02:57

Re: Measure button to pixel full input lag

Post by lexlazootin » 09 Dec 2016, 22:27

Q83Ia7ta wrote:Logitech G100S has have quite low button lag by different tests. This is example:
http://cdn.overclock.net/8/8e/8e56a60d_ ... 150718.png
May be it sound stupid buy why I need debounce?
You have to remember that test is a comparative test, every thing is compared to the G300 and if i remember correctly the G300 has 4-5ms extra latency.

Debounce is to remove bounce from the switch and making a bunch of contacts in a sort amount of time. You can see how keyboard switches make contact under a oscilloscope in the second post.

https://geekhack.org/index.php?topic=42385.0

Basically it just doesn't register the press unless the button/switch has been held down for x+ ms to make sure their are no rapid oscillations. If you have any really bad mice like i have (Steelseries Kinzu v2 Pro) you can rapidly click before the button registers at all.

(Can't they just make the key register as soon as the click is made and then just not register anything after that point for x+ ms?)
Q83Ia7ta wrote:Right mouse button binds to enable crosshair. Left mouse button binds to disable crosshair.
This is much better then using the shot of the gun for measurements. the shot of the gun is tied to the tickrate and can add anywhere between 0-8ms for 128tick and 0-16ms for 64tick.
Q83Ia7ta wrote:Soon I will try to measure BenQ XL2540 but with a such variance (dispersion) like now it will be almost useless.
Good luck! personally i can't wait for the 240hz G-Sync Acer or Asus so i can get one of them and test it :P

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: Measure button to pixel full input lag

Post by flood » 09 Dec 2016, 22:29

fyi you can debounce only button releases to avoid click latency

User avatar
lexlazootin
Posts: 1251
Joined: 16 Dec 2014, 02:57

Re: Measure button to pixel full input lag

Post by lexlazootin » 09 Dec 2016, 22:32

flood wrote:fyi you can debounce only button releases to avoid click latency
wtf, that can't be right.

Why would press have latency and release have none? why not just make the switch upside down or some shit? :lol:

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: Measure button to pixel full input lag

Post by Sparky » 09 Dec 2016, 23:06

lexlazootin wrote:
flood wrote:fyi you can debounce only button releases to avoid click latency
wtf, that can't be right.

Why would press have latency and release have none? why not just make the switch upside down or some shit? :lol:
Say the switch reads closed, you can immediately register the button pressed, but if it reads open you don't know immediately whether it's been released or if it's just bouncing. With a sufficiently high sample frequency you only have to wait the single bounce duration before deciding the switch has been released, but if your sample rate isn't high enough to catch the closed portion of every bounce, you have to wait the whole settle time of the switch.
Last edited by Sparky on 10 Dec 2016, 05:20, edited 1 time in total.

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: Measure button to pixel full input lag

Post by flood » 10 Dec 2016, 00:23

and for avr, using interrupt flags, you can sample continuously

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: Measure button to pixel full input lag

Post by Sparky » 14 Dec 2016, 01:51

Sparky wrote:
lexlazootin wrote:
flood wrote:fyi you can debounce only button releases to avoid click latency
wtf, that can't be right.

Why would press have latency and release have none? why not just make the switch upside down or some shit? :lol:
Say the switch reads closed, you can immediately register the button pressed, but if it reads open you don't know immediately whether it's been released or if it's just bouncing. With a sufficiently high sample frequency you only have to wait the single bounce duration before deciding the switch has been released, but if your sample rate isn't high enough to catch the closed portion of every bounce, you have to wait the whole settle time of the switch.
Just did some testing on new and worn microswitches, and it turns out that even with new switches the single bounce duration can be extremely long while the switch is being continuously held down, like 200ms long, which is actually longer than the time the switch bounces when closing it. (flood pointed this out to me a while ago, but I didn't realize just how easy it was to reproduce this behavior, it's like half of my samples, with just a normal single click). Ended up completely rewriting the program before I figured out what the problem was.

As people can click faster than 200ms, the only option I see that's both fast and accurate is to use SR latch debouncing.

data: https://docs.google.com/spreadsheets/d/ ... q8/pubhtml

code(arduino micro): http://pastebin.com/hjRk3yTE

Let me know if you want a particular graph from that data.

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: Measure button to pixel full input lag

Post by flood » 15 Dec 2016, 23:36

ah yes the latch method
but the danger is if the switch is so worn that the release isn't registered

Post Reply