Setup: macOS 26 (Tahoe), BTT 6.609, Apple trackpad + external mouse (both affected).
Symptom: In any app that pins something under the cursor during a click-drag (mine is a RealityKit game moving a 3D card), the first ~150ms of every drag is frozen: the pointer moves smoothly, but the app receives almost no
leftMouseDragged events — then a burst arrives and the object teleports to catch up.
Evidence it's the event tap:
- CGGetEventTapList shows BTT holding an enabled filtering (not listen-only) tap that includes mouse-drag events, so every mouseDragged round-trips through BTT before apps get it.
- Instrumenting the receiving app: during the dead zone, events arrive 30–80ms late (NSEvent.timestamp vs receipt) and heavily coalesced (200–660px deltas instead of 10–20px); the receiving app's main thread is verifiably idle throughout.
- Quit BTT → completely smooth, instantly and reproducibly. Relaunch BTT → stall is back.
Question: Which BTT features force the filtering mouse tap, and how do I disable them so the tap isn't in the mouse-drag path (or becomes listen-only)? I don't knowingly use any mouse-drag triggers — happy to share my preset or test
settings/beta builds.
Unfortunately these event taps are essential for lots/most of BTT's features, they can not all be disabled individually. (There are lots of subtle issues with enabling / disabling them on demand, BTT does this already where possible)
However there must be something else happening because BTT's event taps should never take more than 5ms (and this is worst case if a lot of triggers are configured that require various testing, verified on thousands of machines and optimized over many years). Unfortunately there can still be issues if multiple apps use the same event taps, BTT does a lot of things to prevent any delays in that case, but not all other apps do the same.
There can also be issues if the system is under heavy load, but these only happen if the CPU usage is > 100% and even then should not result in such a drastic performance drop.
Ah maybe something else: does your app support the accessibility api? Possibly BTT is requesting some accessibility information and the app does not respond quickly, that could explain the issue. However usually that is handled automatically by the system.
You can try to disable these two for your game:
@Andreas_Hegenberg Thank you for your reply.
I never had trackpad or mouse events set up for my game in BTT. The game I'm still developing myself. I've traced everything happening on MainActor, and nowhere in my app the initial "chug" during the drag was caused by my code.
After lots of debugging, i found out it was BTT only, observed via CGGetEventTapList.
I disabled all global trackpad gestures as well, but that didn't help.
I'm not sure why it's taking up such a long window, definitely feels around 100-200ms for me, not the 5ms you argue it would take up.
Is there anything I can help with to find perhaps the root cause via a debug build of BTT you could share or something?
Best regards, Luca ( mesqueeb (Luca Ban) · GitHub )
@Andreas_Hegenberg
Sorry, I initially misunderstood — I read "disable these two for your game" as referring to trackpad/mouse gestures I'd configured, which is why I replied that I never set up any triggers for my game. I now see these can be set globally:
I tested both settings under "For All Apps", toggling them one at a time, and found the culprit: Disable Window Snapping completely fixes the drag delay.
Would it be possible to make the window-snapping AX lookup asynchronous or time-boxed, so a slow-responding app can't stall the event tap? That would protect drags in any app with an expensive accessibility tree, not just mine.
Happy to test a debug build or provide traces if that helps. Thanks for the quick responses!
no that is not possible.
However then it means your game has some issue with the accessibility api. In general these requests are pretty much instant.
If your game does not support accessibility, make sure to disable it for the game's main window so it doesn't even try to respond. This is also important for other accessibility related things like screen readers.
override class func accessibilityIsIgnored() -> Bool {
return true
}
override func isAccessibilityElement() -> Bool {
return false
}
Or even more complete:
final class AXHiddenWindow: NSWindow {
override func isAccessibilityElement() -> Bool {
false
}
override func accessibilityChildren() -> [Any]? {
[]
}
override func accessibilityVisibleChildren() -> [Any]? {
[]
}
override func accessibilityChildrenInNavigationOrder() -> [Any]? {
[]
}
override func accessibilityHitTest(_ point: NSPoint) -> Any? {
nil
}
override func accessibilityFocusedUIElement() -> Any? {
nil
}
override class func accessibilityIsIgnored() -> Bool {
return true
}
}
