Interesting. It doesn't happen here on the same code and version of OS. It's very possible that World of Tanks is resetting the Windows cursor clip rectangle while in the background. That would be a bug in the game, and would definitely interfere with this test.

Try running this autoit script in the background instead of World of Tank and see if it recreates the behavior:

opt('guioneventmode',1)
guicreate('')
guisetstate()
guisetonevent(-3,quit)
while sleep(1000)
    dllcall('user32.dll','bool','ClipCursor','struct*',Null)
wend
func quit()
     exit
endfunc

A workaround would be to run GetClipCursor on every WM_MOUSMOVE and send ClipCursor if it's not the right clipping range. In relative mode you should never receive WM_MOUSEMOVE because the cursor is constrained to one pixel.

It's very possible that World of Tanks is resetting the Windows cursor clip rectangle while in the background. That would be a bug in the game, and would definitely interfere with this test.

This is exactly it.

I've run the C# equivalent of @expikr's while(true) ClipCursor(NULL); code and it behaves the same as having World of Tanks in the background. I'll be sure to report the bug to the devs.

SDL will update the ClipCursor every 3 seconds, so it can recover if an external app (accidentally) sets it to the wrong value once.

I'm eager to close this issue as "not SDL's problem", but I think adding logging would be helpful for pointing the blame onto other running programs.

Something like "ClipCursor rect changed unexpectedly (is another program changing it?). Resetting to expected location,"