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:
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?
Measure button to pixel full input lag
- lexlazootin
- Posts: 1251
- Joined: 16 Dec 2014, 02:57
Re: Measure button to pixel full input lag
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?
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?
Re: Measure button to pixel full input lag
Just found it. Thanks!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 :?:
Logitech G100S has have quite low button lag by different tests. This is example: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.
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.
i5-6600 not K :)lexlazootin wrote:You have a pretty strange system there? 6600k with a 950? LTSB 32-bit?
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.
- lexlazootin
- Posts: 1251
- Joined: 16 Dec 2014, 02:57
Re: Measure button to pixel full input lag
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.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?
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?)
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:Right mouse button binds to enable crosshair. Left mouse button binds to disable crosshair.
Good luck! personally i can't wait for the 240hz G-Sync Acer or Asus so i can get one of them and test itQ83Ia7ta wrote:Soon I will try to measure BenQ XL2540 but with a such variance (dispersion) like now it will be almost useless.
Re: Measure button to pixel full input lag
fyi you can debounce only button releases to avoid click latency
- lexlazootin
- Posts: 1251
- Joined: 16 Dec 2014, 02:57
Re: Measure button to pixel full input lag
wtf, that can't be right.flood wrote:fyi you can debounce only button releases to avoid click latency
Why would press have latency and release have none? why not just make the switch upside down or some shit?
Re: Measure button to pixel full input lag
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.lexlazootin wrote:wtf, that can't be right.flood wrote:fyi you can debounce only button releases to avoid click latency
Why would press have latency and release have none? why not just make the switch upside down or some shit?
Last edited by Sparky on 10 Dec 2016, 05:20, edited 1 time in total.
Re: Measure button to pixel full input lag
and for avr, using interrupt flags, you can sample continuously
Re: Measure button to pixel full input lag
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.Sparky wrote: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.lexlazootin wrote:wtf, that can't be right.flood wrote:fyi you can debounce only button releases to avoid click latency
Why would press have latency and release have none? why not just make the switch upside down or some shit?
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.
Re: Measure button to pixel full input lag
ah yes the latch method
but the danger is if the switch is so worn that the release isn't registered
but the danger is if the switch is so worn that the release isn't registered