Mousemove gets dispatched at least once every time a pointer position change "in pixels" is detected. Use a high-resolution timer to obtain temporal information. Some "legacy" timers might also do it in theory but in practice their granularity is insufficient.
Raw input is dispatched every time the controller reports a state change. Because it is unfiltered, this will be much, much higher frequency.
As far as I've understood, the device produces a constant stream of data (to its integrated controller) at a steady rate, but I doubt the data to be steadily streamed to host. This is very likely implementation-dependent and you're not really concerned with this anyway.
I did not understood how you see it, If once a position change it pixels is detected imo it brings to
1) frequenzy resolution at which it is detected
2) if no it would be mean (as mouse ball move is probably continuous not hard jumps) that the mouse move should appear
afret each one pixel change, so gesture 400 pixels long should
move 400 mouse move events 1 pixel long each
(though i must rethink the answer a bit yet)
Ps when i did some test it shows that mouse move events
seem to depend on frame time, if I run my app with 100 ms
frame time It seem I got only one mouse move with sum up values - It seemed like windows would queue the mouse moves internally and on each query at message pump gives only one
sume up value - so it seem just that mouse reselotion depends on frame time (this is for normal wm_mousemove events,
I dont know how it is for rawinput)
Edited by fir, 27 March 2014 - 03:32 AM.