A post on a Japanese forum i found recently shows the response time of a mouse click is not directly tied to the polling rate of the mouse. http://utmalesoldiers.blogspot.com.au/2013/02/114.html The graph in that post uses the Logitech G300 as a base line because they are simply comparing mice with each other and not starting the timer from the initial click. they were using the Mouse Shooting Speed Test v1.6 software at http://www.bloody.tw/cn/download.php for the test.
just shows that testing of different mice could have a different result in a "Click to shoot" test found in the forum post "Preview of NVIDIA G-SYNC, Part #2 (Input Lag)" but Chief Blur Buster was lucky enough to use one of the most responsive mice on the graph below (G9x)
Although I'm not sure how they messured their testing in this graph, it might be helpful if you want to find the full reaction time from the initial click.
http://cdn.overclock.net/6/63/6317907b_1070rk7.gif
i feel kinda important for finding this but you guys probs already knew
Inherent click delay found in mice.
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: Inherent click delay found in mice.
this issue was (sort of) raised here by flood, in his esreality post (he's ewh there): http://esreality.com/post/2691945/micro ... pid2692878
The idea (and not sure if this is true) is that when "dormant", the first mouse event, whether it be a click or a movement will be registered in a millisecond, regardless of polling rate.
But continuous events, such as moving the mouse, or clicking while moving, will be limited by the polling rate. So with a 125 hz USB polling rate, if you move the mouse from a standstill, the first movement may occur within 1 ms, but if you then suddenly change the speed of your hand movement, there will be as much as an 8 ms delay before this acceleration is registered.
I'm also assuming that clicking and moving share the same polling stream, so if you are moving a mouse (@ 125hz) and click it while in motion, the click itself will be delayed as much as 8 ms.
If I'm correct, then that japanese article is a bad example of ecological validity. Often in gaming we are moving the mouse while we click to shoot.
The idea (and not sure if this is true) is that when "dormant", the first mouse event, whether it be a click or a movement will be registered in a millisecond, regardless of polling rate.
But continuous events, such as moving the mouse, or clicking while moving, will be limited by the polling rate. So with a 125 hz USB polling rate, if you move the mouse from a standstill, the first movement may occur within 1 ms, but if you then suddenly change the speed of your hand movement, there will be as much as an 8 ms delay before this acceleration is registered.
I'm also assuming that clicking and moving share the same polling stream, so if you are moving a mouse (@ 125hz) and click it while in motion, the click itself will be delayed as much as 8 ms.
If I'm correct, then that japanese article is a bad example of ecological validity. Often in gaming we are moving the mouse while we click to shoot.
- lexlazootin
- Posts: 1251
- Joined: 16 Dec 2014, 02:57
Re: Inherent click delay found in mice.
I could be wrong but flood sounds like a fucking awesome dude.
I kinda feel like using arduino as a mouse isn't a real world scenario and is kinda cheating, if you could explain to me why that post is wrong or if you could ask flood nicely for me to do a similar test with a REAL mouse (Like the g100 he has laying) with the light sensor i would be one happy chap
EDIT: btw i'm talking about a click delay not a movement delay!
I kinda feel like using arduino as a mouse isn't a real world scenario and is kinda cheating, if you could explain to me why that post is wrong or if you could ask flood nicely for me to do a similar test with a REAL mouse (Like the g100 he has laying) with the light sensor i would be one happy chap
EDIT: btw i'm talking about a click delay not a movement delay!
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: Inherent click delay found in mice.
I'll let him give a more thorough answer, but the quick one is that his tests were designed to examine the delay from the register of the poll to the phosphors lighting up on display. The arduino achieves this without any uncertainties regarding delays that might occur through particular mouse drivers/firmware, poor circuit design, or poor button design.lexlazootin wrote:I could be wrong but flood sounds like a fucking awesome dude.
I kinda feel like using arduino as a mouse isn't a real world scenario and is kinda cheating, if you could explain to me why that post is wrong or if you could ask flood nicely for me to do a similar test with a REAL mouse (Like the g100 he has laying) with the light sensor i would be one happy chap
EDIT: btw i'm talking about a click delay not a movement delay!
As for click vs movement delay, I think they're fundamentally the same as far as the USB poll register is concerned.
Re: Inherent click delay found in mice.
there probably is a significant inherent delay due to debouncing code in the firmware
- lexlazootin
- Posts: 1251
- Joined: 16 Dec 2014, 02:57
Re: Inherent click delay found in mice.
A whole 30ms of it Is this is the reason I'm pretty unhappy with steelseries for creating such a massive delay in their low-end miceflood wrote:there probably is a significant inherent delay due to debouncing code in the firmware
- Chief Blur Buster
- Site Admin
- Posts: 11653
- Joined: 05 Dec 2013, 15:44
- Location: Toronto / Hamilton, Ontario, Canada
- Contact:
Re: Inherent click delay found in mice.
Debounce can be done after button release, not the button press side. In gaming mice, there shouldn't be debounce delay -- in theory, anyway.flood wrote:there probably is a significant inherent delay due to debouncing code in the firmware
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter
Forum Rules wrote: 1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
2. Please report rule violations If you see a post that violates forum rules, then report the post.
3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!
Re: Inherent click delay found in mice.
hm yea that should be how things work...
Re: Inherent click delay found in mice.
For debounce to do what it is intended to do it cannot be applied after button release.
There is the possibility of debouncing only after the initial actuation, but that is not worthwhile in mice as quick double-clicking wouldn't be possible. In mice, debounce has to be of the "call state stable after Xms" type as opposed to the "call state unstable for Xms after event" type sometimes found in keyboards.
Optical microswitches would allow us to get rid of debounce altogether.
There is the possibility of debouncing only after the initial actuation, but that is not worthwhile in mice as quick double-clicking wouldn't be possible. In mice, debounce has to be of the "call state stable after Xms" type as opposed to the "call state unstable for Xms after event" type sometimes found in keyboards.
Optical microswitches would allow us to get rid of debounce altogether.
Re: Inherent click delay found in mice.
Debounce doesn't have to delay the initial pressed status, and if the button is held by the user for more than 10-20ms, then release doesn't have to be delayed by debounce either. In both cases, the controller waits for a button state change, immediately reports it, and then ignores changes for 10ms or so.
An analog switch with hysteresis (schmitt trigger) would avoid bounce, an optical switch being an instance of this as you say.
An analog switch with hysteresis (schmitt trigger) would avoid bounce, an optical switch being an instance of this as you say.