Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
That is so stupid... They probably want it to seem like a "free upgrade" that they are giving you. Not a big fan of manipulative companies.mulz wrote:I heard finalmouse will release a tool at some point where you can upgrade your finalmouse ultralight pro from 500hz to 1000hz. Btw, It seems very interesting mouse!
It does seem interesting as a mouse, i would like to try it but it does look a little big.
Chief, I've gotta say I've been giving your post quite a bit of thought over the last little while and I wanted to throw in a few more pieces to the puzzle. The situation is even less clear in-game.Chief Blur Buster wrote:
TL;DR: Your mileage will vary with 500 Hz mice on 240 Hz displays. But why do mouse manufacturers stay that low?
It is true that, assuming a fixed framerate = refreshrate scenario (240hz monitor with 500hz mouse), every 25 frames will produce an extra poll that will cause a cursor skip, even in a mouse gliding at constant velocity across a surface (perfect tracking assumed). In fact, this is easily observable on your desktop by switching your mouse to a 500hz mode and moving the cursor across a dark background -- the gaps will be very apparent and concerning.
However, in a game, it is rarely the case that the framerate is permanently fixed at the refresh rate -- even if a framerate cap is introduced (and enforced by a mechanism such as yield, sleep, etc), sudden dips can occur as a result of changes occurring within the game itself. This may only manifest for a fraction of a second, but it will still impact the number of input loop iterations per second. Perhaps it might take an extra 2 milliseconds to run the input polling section of the game loop in a single threaded game, for example -- it may be within the ~4.16 millisecond window that a 240hz monitor demands, but these small variances in timing can eventually add up to collect that extra mousepoll even when things appear to be timed right at the high level (i.e. looking at your FPS counter and seeing a locked 240 frames per second isn't enough). Even if you were running a multiple of the refreshrate as the polling rate (for example 960hz USB polling rate with a 240hz monitor, which AFAIK is not possible on Windows and maybe not even at the hardware level), you would still observe these "jumps" with otherwise constant velocity from the mouse (which are multiple poll results added together), and this would be more noticeable in a vsync-on setup (adaptive sync or not), since the entire frame is visible.
Now, in an FPS uncapped scenario, the game loop may be running far in excess of what the monitor is capable of displaying and instead the graphics driver is permitting screen tearing to occur in order to ensure the absolute latest information is present on the display at any given moment. In such a case, I argue that the mouse movement will be smoother relative to a locked framerate and will not display the same "jumping" or "skipping" behavior as observed in the previous paragraph. Why? To start, the game engine loop is running at significantly faster than the monitor refresh rate and part of that loop is polling the mouse information being accumulated by the OS (which is accumulated at the polling rate of the mouse). (*greatly*) Simplified Diagram:
Game engine polling <=> Operating system <=> Mouse
(where <=> indicates bidirectional communication)
The game engine polls the operating system at it's own fluctuating framerate. The operating system itself is polling the USB bus for changes at the specified USB polling rate and accumulating in a buffer the sum total of all changes made. When the game engine polls the operating system, that buffer is reset to zero and the changes are sent to the receiving entity (the game engine), which includes but is not limited to the changes in X, Y, scroll wheel, and the changes in button states.
Hence, the game engine itself is able to receive information from the mouse at a higher rate than the display's refreshrate and is able to respond to those changes accordingly. Since the framerate is uncapped and screen tearing is in place, you'll see these changes happening on your monitor directly, although at possibly different regions of the screen. Yes is is true -- you will have a varying number of mousepolls per game loop iteration -- likely more than the locked framerate approach, but your overall input latency will be lower too (the input buffer is getting read more frequently than it would otherwise and the curve of motion will be more accurately reproduced on screen).
So it seems that no matter what you do, your frames may be receiving a varying number of mousepolls-worth of information on each update of the input loop. You may receive 5 one iteration and 3 the next. If you're locked at a certain framerate, it will help even it out, but still can't entirely eliminate it -- and then you get more latency anyway.
So, I argue the following:
- that this situation is actually happening already, and frequently
- we're already very accustomed to these variances in the number of mousepolls per perceived frame
- more USB polling hz can't eliminate this problem -- but it can help with other things like latency at least, when the number of frames per second is high enough to take advantage of it
- 500hz on a 240hz monitor won't be significantly worse than 1000hz on the same monitor in-game, so long as the framerate is uncapped and you are getting sufficient frames per second to reproduce the motion of the mouse accurately (rough estimate, 300).
- The benefit from increased USB polling rates is only realized when there is sufficient corresponding frames (or input/game loop polls) per second to realize the smoother motion on screen