Dragging windows with modifier keys has high latency in build 1507 (and other builds of 3.332), but not in 3.331

Describe the bug
I use the window moving and window resizings features with modifier keys many, many times during the day. (I hold down command+option to move a window, and shift+option to resize it.)

I noticed a significant change in modifier key → move/resize latency in 3.332 that's not present in 3.331 (see build numbers below).

The delay might be around the 100msec range, which seems quick, but a few frames of mouse movement usually means my mouse is over another window, or that I ended the resize operation several frames ago.

Versions tested
Good:

  • 3.331 (1506)

Bad: (via https://bettertouchtool.net/releases/)

  • 1507

Bad (released)

  • 3.332 (1519) and latest alpha (3.332 (1521))

Affected input device (e.g. MacBook Trackpad, Magic Mouse/Trackpad, Touch Bar, etc.):
Affects internal trackpad and external trackpad. Have not tested with an external mouse yet.

Screenshots
I'm working on getting a screen recording to show the difference in latency. It's perceptible in A/B tests but I don't have an app that shows held modifier keys to show the delta from release → window move.

Device information:

  • Type of Mac: MacBook Pro 15" (mid-2019)
  • macOS version: 10.14.6 (18G3020)
  • BetterTouchTool version: (please post the exact version - not just "the latest one")

I've tested each build from 1506–1521, including:

  • 3.331 (1506)
  • 3.332 (1519)

Hey, good guess, it's exactly 100ms. I'm experimenting with some performance improvements to prevent BTT from needing to recalculate e.g. displayed Touch Bar buttons on every modifier key press (e.g. when pressing cmd+option+x people usually don't press both modifiers at the same time, so BTT needs to spend twice the time on the processing because cmd and opt are handled separately)

However you are right, for window resizing this doesn't make sense. I have removed the delay in build 1522 (online in a few minutes)

Ha, what a guess! Super, thank you. I'll try that out and report any issues I hit. (And thanks for linking to the per-build versions, it made it easy to narrow down which build started doing this.)

build 1523 is exhibiting a bug where the window resize/move modifiers are toggled backwards:

when I hold cmd-opt and move the mouse, nothing happens to the window underneath the cursor, but when I release it, the window starts moving with the mouse pointer.

the same thing happens for resize: once I press and release the modifiers, BTT is basically stuck in "resize what's under the cursor" until I hold shift+opt; while they're held down, it doesn't resize the window.

Uh you are right, sorry. Fixed in 1524 (online in ~5min)!

:+1: looks great, thanks!

So, I use cmd + shift to move windows and alt + shift to resize windows. For some reason, I have to press shift twice in order to stop dragging or resizing. If I try to move/resize a window using modifier keys, the move/resize continues even after I un-press the modifier keys. This started happening just now after I updated to 3.332. Is there anything I can do to help solve this? I used karabiner-elements EventViewer to see if the keys were actually being released, and they were, so I'm not sure why BTT isn't letting go of the window....

edit: wait, I reread the comments above and downloaded 1524. Everything works now! Thanks :]

1 Like