Ya, I already checked that. Mouse software is on both machines.
As well, it happens with regular (non-software requiring) mice.
As you can see in the video, moving the mouse (non-drag) is all very responsive and correct. It's only the dragging that shows issues.
No CPU strain. Everything else works very nicely.
Even stranger... If I drag to the left... pause, drag to the right... pause... etc (giving plenty of time during the pause for any lag to catch up), the MOVE happens in time (sync), but will sometimes continue in the last direction, rather than in the opposite... and then part way through that move, the direction suddenly changes to the proper direction. This is during a drag which is only going one direction. Again, the MOVE is in sync, but the change in direction is often 'delayed'. Doesn't matter how long you pause for.
It doesn't seem to be a TIME-based delay (in that giving it 'catch up' time doesn't help). It's more like the move is running at one frame rate, and the direction switch 'signal' is at a slower rate, and they go out of sync.... completely independent of each other, with the change of direction not happening at the start of the move, but somewhere during it.
It's hard to see in the video (since the issue causes the dragged object to go firing off the screen), but if you watch the connecting/measurement line you will see when the direction changes during any offscreen drags. I keep the same timing/pacing of the move, pause, move, pause, always alternating from left to right... and you can see on some moves, the direction changes partway through the move, rather than the move being one direction only (as it should be).
Is there no way we can get feedback from the programmers on what might cause this sort of thing? As things are, it's impossible to do any work, as the objects I am trying to move are just flying off the screen every time I try and carefully move them.
Stardock Forums
