There has been a bug around for ages, that results in the mouse suddenly jumping to the middle of the screen or other erratic behavior. A simple google search for "wow mouse jumping" shows up a ton of results going back for years. Blizzard has even created a dedicated page to this issue over here: https://eu.battle.net/support/en/article/000014597
Proposed solutions have always involved the following things, among others: Disabling third party mouse software, disabling max foreground FPS, enabling/disabling vsync, disabling/enabling hardware cursor. There isn't a single solution that works for all people, but the proposed solutions have been successful in some cases. So what's up? Turns out the root cause of the issue has always been a race condition. Playing with settings like these make the race condition less/more likely to resolve correctly. So what's really going on? People playing World of Warcraft on Linux through Wine have analyzed the winAPI calls that are being made. Schematically, WoW does something like this:
OnMouseButtonPressed(): HideCursor() SaveCurrentCoordinates() WarpToWindowCenter() OnMouseButtonRelease() ShowCursor() WarpToSavedCoordinates()
So when you press the mouse, it's is hidden, the current coordinates are saved, and the mouse is moved to the middle of the window. When you release the mouse button, the cursor is shown and warped to the saved coordinates so it appears at the same location where you left it.
However, in the winAPI (and under wine as well), it is NOT allowed to warp the cursor while it's visible, since you'd then have a program moving the mouse cursor. So why does this piece of code still work in most cases? We have a classic race condition: ShowCursor() will complete as soon as possible, so it doesn't lock the thread that is executing this command. What it actually does, is that the cursor will be made visible on the NEXT frame. Therefor, the WarpToSavedCoordinates() command will still be able to move the cursor while it's still invisible.
If WarpToSavedCoordinates() is quick enough, this code will work fine, but if the cursor is already visible, the cursor cannot be moved. This means for the end user, the cursor will appear/jump in the middle of the screen, because the cursor was moved to the middle of the screen during the OnMouseButtonPressed() code.
The fix for this issue is incredibly easy: Simply swap the commands around, so that the cursor is always moved while it's still invisible, removing the race condition. The resulting pseudo-code would look like this:
OnMouseButtonPressed(): HideCursor() SaveCurrentCoordinates() WarpToWindowCenter() OnMouseButtonRelease() WarpToSavedCoordinates() ShowCursor()
I have contemplated just sending a bug report to Blizzard, but I'd probably get a canned response and nobody will ever look into it. I was hoping this topic might get some traction here, so Blizzard will see it and actually look into it. As far as we can see, the fix is really as simple as swapping two API calls around. For reference where these findings are discussed: https://gitlab.freedesktop.org/xorg/xserver/-/issues/734
Source: Original link
© Post "Identified root cause of age old bug: Mouse randomly jumping to the middle of the screen" for game World of Warcraft.
Top 10 Most Anticipated Video Games of 2020
2020 will have something to satisfy classic and modern gamers alike. To be eligible for the list, the game must be confirmed for 2020, or there should be good reason to expect its release in that year. Therefore, upcoming games with a mere announcement and no discernible release date will not be included.
Top 15 NEW Games of 2020 [FIRST HALF]
2020 has a ton to look forward to...in the video gaming world. Here are fifteen games we're looking forward to in the first half of 2020.