AltSnap
AltSnap copied to clipboard
RamonUnch
High Polling Rate Zone Dragging
Since I use a mouse with a 1000Hz polling rate, instead of the old standard of 125Hz, zone snapping became jittery and in a few cases unreliable. The main factor is the responsiveness of the application, the lower the worst. It seems the window can't keep up with the sudden resize changes when changing zones by dragging and a 1000Hz refresh.
Refresh has no effect.
A higher ResizeRate makes the issue even more pronounced.
The only parameter which diminishes the issue is Moverate.
So the solution could be to internally increase the MoveRate while zone dragging (shift+drag).
As no visible window movement takes place, it wouldn't even be noticeable by the user.
Actually a windows should not be resized to its current size, if it does not move it should not be doing any work, I will investigate the problem further...
Also setting RezTimer=1 might help in your case.
Actually a windows should not be resized to its current size, if it does not move it should not be doing any work, I will investigate the problem further...
The judder takes place when switching zones: https://github.com/RamonUnch/AltSnap/assets/31080003/67d580c3-69e3-40a3-9001-0a8f6484d010
Also setting RezTimer=1 might help in your case.
Already tried, didn't help, same with ZSnapMode.
Higher MoveRate helps.
Higher ResizeRate makes it worse.
Quick test version! Might help, unsure... Thanks for reporting.
well the issue with increasing too much the MoveRate is that you will loose precision in movement.
It is not a big deal if you use snapping. Bt basically if you set MoveRate to 4, 1000Hz is more or less transformed into 250Hz.
Yes, even low values of MoveRate can fix it. In my case MoveRate=2 minimizes the issue, MoveRate=3 almost eliminates it and MoveRate=4 fixes it. That is, tested with the File Explorer and 1000Hz.
Considering there are even less responsive applications and the USB standard allows up to, 8000Hz, an additional setting would probably the best. MoveRateWhileSnapping or something. A hard-coded Moverate could never address 125Hz to 8000Hz.
To get it 100% right, I tested some more demanding (opengl/Vulkan 3D accelerated) applications and thus even less responsive windows.
Even with test20 I need a moverate of 8, which renders my effective polling rate to the old standard of 125Hz (1000Hz/8), to eliminate the glitch 100%.