Inherent click delay found in mice.

[lexlazootin]

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

[spacediver]

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.

[lexlazootin]

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!

[spacediver]

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'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.

As for click vs movement delay, I think they're fundamentally the same as far as the USB poll register is concerned.

[flood]

there probably is a significant inherent delay due to debouncing code in the firmware

[lexlazootin]

there probably is a significant inherent delay due to debouncing code in the firmware

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 mice

[Chief Blur Buster]

there probably is a significant inherent delay due to debouncing code in the firmware

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]

hm yea that should be how things work...

[stirner]

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.

[blargg]

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.