Measure button to pixel full input lag

Everything about input lag. Tips, testing methods, mouse lag, display lag, game engine lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more!

Re: Measure button to pixel full input lag

Postby flood » 16 Dec 2016, 00:28

subjective notes to be tested tomorrow:

old pc, de_nuke ct spawn, max graphics settings (heavily gpu-limited rendering)
mat_queue_mode 0: ~111fps, reference
mat_queue_mode 1: ~111fps, feels same as reference
mat_queue_mode 2: ~111fps, feels laggier than reference

fps_max 100
all three settings now feel more responsive than reference

edit:
actually, not sure. there are just my initial impressions, and of course biased by my existing knowledge
maybe mqm1 uncapped is better than mqm0 uncapped.
flood
 
Posts: 880
Joined: 21 Dec 2013, 01:25

Re: Measure button to pixel full input lag

Postby Sparky » 16 Dec 2016, 03:48

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


I haven't noticed any clicks that failed to release over a couple thousand clicks with interrupt based latched debouncing, though that contact has only been worn mechanically, not electrically (because the mouse left that pin unconnected). There is a lot more bouncing on the NC contact than the NO contact(when the button is released or pressed respectively), but that is true of the new switch as well.

For latched debouncing we only need intermittent contact. By the time a switch has worn to the point where there isn't any signal whatsoever on the NC contact, the NO contact will be hopelessly worn as well, far beyond any single contact debouncing method I'm aware of.

I wasn't able to make it malfunction in this manner with simple finger pressure. While I was able to hold the NC contact open with finger pressure, it wasn't enough to keep the snap action from making momentary contact during a slow release. I believe it's a matter of rigidity, as the force increases during the snap action of the switch, and if the finger pressure doesn't increase as fast as the spring force, the common contact gains enough momentum to make NC contact. It was possible with a lever to release the button slowly enough that the switch didn't click on the release, and when this happened I was able to click the button down without the NC contact closing.
Sparky
 
Posts: 491
Joined: 15 Jan 2014, 02:29

Re: Measure button to pixel full input lag

Postby Chief Blur Buster » 19 Dec 2016, 14:01

In theory, with properly engineered hardware, the debounce is programmable on the computer end (which might send a signal to the mouse to use new microcontroller logic). In theory, you could adjust everything related to debounce logic in 100% software from the PC end -- e.g. debounce presses or releases or both, and adjust thresholds (10ms, 50ms 100ms, "X" ms, etc). I wish it was exposed in many more mouse drivers!

The ideal debounce for a very mechanically reliable button could be done only on the button-release end, so you can avoid MOUSEDOWN latency -- since games often trigger actions on the press rather than the release. And that the mouse button is mechanically new enough that ultra-short debounce logic (<50ms) only on the releases, would be fully reliable for your gaming habit. If it starts being less reliable, then just replace mouse or lengthen threshold via a theoretical advanced mouse control panel (if you're able to set a new threshold that's still acceptable, i.e. you're physically unable to click faster than the new debounce threshold).

Has any mouse manufacturers started exposing large numbers of adjustable settings for custom control of debounce logic?
To allow "Choose-Your-Own-Debounce-Logic" via Control Panel?
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3250
Joined: 05 Dec 2013, 15:44

Re: Measure button to pixel full input lag

Postby Q83Ia7ta » 19 Dec 2016, 21:23

I have done some tests with my new method with BenQ XL2540 and Asus PG248Q. Simple directx9 app (thanks blurbuster flood a lot!), vsync off, high fps. dunno why but I get only 6000-6700 fps depending on refresh rate.
Left mouse button changes screen color to black, right to white. raw mouse input. Camera captures black to white transition and LED at right mouse button.

Results are:
dae.png
dae.png (22.46 KiB) Viewed 2283 times

I highlighted only same refresh rate.
app source: http://pastebin.com/XyfhU5nE
1200fps videos: https://drive.google.com/file/d/0B_8ge_ ... sp=sharing

Next step is to make tests on both monitors at Quake Live. Quake Live because I perform much better at PG248Q at 170Hz than XL2540 at 240Hz. Values will higher for sure. max fps 250 is one of the reasons.
May be Quake Live engine (not directx9) works wrong at such high refresh rate. May be almost same full input lag (mouse button to pixel latency) affects my aim and overall feelings. May be I need to unbox and try GTX 1060 instead GTX 950...
Any ideas?
Q83Ia7ta
 
Posts: 590
Joined: 18 Dec 2013, 09:29

Re: Measure button to pixel full input lag

Postby lexlazootin » 20 Dec 2016, 10:27

Q83Ia7ta wrote:dunno why but I get only 6000-6700 fps depending on refresh rate.


to get 16k i run at 800x600

But yea, the results are very weird. I felt like if the monitor was made correctly it would have less latency.

Can you please send me the compiled windows version of your build, i would love to see if i can get that low latency with my mouse click, you using rinput or something?
lexlazootin
 
Posts: 819
Joined: 16 Dec 2014, 02:57

Re: Measure button to pixel full input lag

Postby lexlazootin » 20 Dec 2016, 10:44

Chief Blur Buster wrote:The ideal debounce for a very mechanically reliable button could be done only on the button-release end, so you can avoid MOUSEDOWN latency -- since games often trigger actions on the press rather than the release. And that the mouse button is mechanically new enough that ultra-short debounce logic (<50ms) only on the releases, would be fully reliable for your gaming habit


I'm really not too sure if i understand.

So are you saying that RIGHT NOW mouse debounce is only applied to the mouse-down but not on the mouse-up? if that's the case wouldn't you have the same electrical bouncing interference ether way? It doesn't make any sense to me.

Couldn't you just keep checking until the click and then just ignore all input for 10ms remove all debounce and latency?

Like this?: http://imgur.com/wXr69FU
lexlazootin
 
Posts: 819
Joined: 16 Dec 2014, 02:57

Re: Measure button to pixel full input lag

Postby Sparky » 20 Dec 2016, 11:19

lexlazootin wrote:
Chief Blur Buster wrote:The ideal debounce for a very mechanically reliable button could be done only on the button-release end, so you can avoid MOUSEDOWN latency -- since games often trigger actions on the press rather than the release. And that the mouse button is mechanically new enough that ultra-short debounce logic (<50ms) only on the releases, would be fully reliable for your gaming habit


I'm really not too sure if i understand.

So are you saying that RIGHT NOW mouse debounce is only applied to the mouse-down but not on the mouse-up? if that's the case wouldn't you have the same electrical bouncing interference ether way? It doesn't make any sense to me.

Couldn't you just keep checking until the click and then just ignore all input for 10ms remove all debounce and latency?

Like this?: http://imgur.com/wXr69FU


Depends on the switch, but probably not with mouse switches, as you get some really ugly intermittent contact when you release the button, so you're likely to get extra clicks. IMO the only good option is to use the normally open contact to decide the button has been pressed, and the normally closed contact to decide the button has been released. Preferably by using two pins on the microcontroller. The second best option is to connect the common contact of the switch to the microcontroller and the NC and NO pins of the switch to opposite power rails, though you'd want an extra resistor and cap in there to keep the pin from floating while you're putting pressure on the switch but not yet clicking it, and to smooth out the transition.
Sparky
 
Posts: 491
Joined: 15 Jan 2014, 02:29

Re: Measure button to pixel full input lag

Postby Trip » 20 Dec 2016, 19:43

Q83Ia7ta wrote:Next step is to make tests on both monitors at Quake Live. Quake Live because I perform much better at PG248Q at 170Hz than XL2540 at 240Hz. Values will higher for sure. max fps 250 is one of the reasons.
May be Quake Live engine (not directx9) works wrong at such high refresh rate. May be almost same full input lag (mouse button to pixel latency) affects my aim and overall feelings. May be I need to unbox and try GTX 1060 instead GTX 950...
Any ideas?

Maybe its because of ghosting that you perform a little less with the benq I read in the hardware.info review that some pixel transitions took longer then 4ms. I think the asus also had a similar problem if you would run it at 180hz instead of 170hz. Could be if you tinker with the refresh rate or the overdrive it plays as well or better then the asus. It would be very strange if the monitor refresh rate influences a game that is not run with vsync and I have never heard of such a case. Skyrim and fallout behaved wrong with high refresh rate screens because they depended on vsync as their fps cap but quake does not care about that as far as I know.
Trip
 
Posts: 152
Joined: 23 Apr 2014, 15:44

Re: Measure button to pixel full input lag

Postby dhaine » 22 Dec 2016, 10:04

nice work Q83Ia7ta
please keep us updated if you find out why you are doing worse on the 240hz
from your tests it doesn't seem to be related to input lag since that panel is still the fastest, i'm surprised it's such a small margin compared to a 144hz monitor, by the way did you also test the korean 220hz monitor ?
dhaine
 
Posts: 34
Joined: 22 Nov 2014, 00:25

Re: Measure button to pixel full input lag

Postby Q83Ia7ta » 23 Dec 2016, 08:31

dhaine wrote:from your tests it doesn't seem to be related to input lag since that panel is still the fastest, i'm surprised it's such a small margin compared to a 144hz monitor, by the way did you also test the korean 220hz monitor ?
I didn't test it because i dissasebled monitor and used panel with ZisWorks 240Hz DVI board.
Q83Ia7ta
 
Posts: 590
Joined: 18 Dec 2013, 09:29

PreviousNext

Return to Input Lag

Who is online

Users browsing this forum: No registered users and 3 guests