Dragging with mouse modifier is not as smooth as native window movement

[haze]

See here
The first drag is using a click and drag on the window border, while the second is using the mouse modifier. Is there any way to make this smoother?

[koekeishiya]

I have an idea of how to do this better now, yeah. Will try to find time to implement it during this weekend.

[haze]

@koekeishiya is there also plans on improving the latency on resize + move event ingestion? it seems like it is throttled. Holding down the keybind turns transforms minutes of window lag.

[dominiklohmann]

defaults write -g NSWindowShouldDragOnGesture -bool true

Run the above, then reboot. You can now resize windows from anywhere by holding ctrl + cmd (which, if fn is not an option, is the only availabale two modifier key combination that's free for mouse actions).

Maybe there's a way to trigger this behavior with a custom shortcut?

[koekeishiya]

Removed throttling for mouse-drag movement. This is possible because we can use the scripting-addition to move the window in this scenario. We avoid the conflicting issue where we try to use the AX API and the CGS API simultaneously (frame synch issues) that I noticed earlier when trying to get rid of the AX API for.

I've reduced the throttling applied when resizing a floating window drastically, and lowered it for tiled windows as well, but resizing through the AX API is inherently not a cheap operation. A potential solution would be to inspect all events sent to the window when performing a native corner resize, isolate the relevant events, and simulate said sequence of events from yabai.

Now there is some part here that we are not in control of, if that is what you are referring to.
When a window is moved or resized, we get notified by the operating system and act accordingly. This is mostly used for update the frame of window borders. The delay that you see here is not something that we are able to affect.