Hi. For the past month or two, I’ve been having issues with BTT’s menu bar menus and custom context menus being really slow. They lag terribly when I move the mouse over them, and it can sometimes take up to a second for individual items to become active.
The weird thing is that if I try to record this using Cmd+Shift+5, the menus become perfectly smooth. It’s as if the recording process activates something that makes the menus faster.
I recently did a clean reinstall of Golden Gate on my MacBook Air M5, so performance shouldn’t be an issue. Any idea what might be causing this?
It behaves the same way even after restarting my Mac. Nothing is visibly using much CPU; the biggest process is actually BTT, which is only using a few per cent. Other menus in macOS work normally, only the ones from BTT are laggy. I recorded it on my phone, so you can see what I mean. The system recording seems to fix it, as if it were clearing some kind of bottleneck.
Is there any way to generate a log for this? Or how should I go about troubleshooting it to identify the issue?
Thanks for looking into this. I’ve sent you the file. The strange thing is that the menus were running quickly while I was logging. But you might still find something.
I don’t have Low Power Mode enabled, and I can’t see any reason why the system would be throttling performance. There’s no load to speak of, and temperatures are low. Unless it’s some kind of aggressive macOS policy that automatically limits third-party processes.
The slow window server response could maybe point to the window server being overloaded. Maybe some feature in BTT causes it create windows and not properly release them so they accumulate? Does the issue happen right after starting BTT or only after some time?
This command would count the BTT windows (a few are always there because this also includes inivisible windows and e.g. the menubar status item)
osascript -l JavaScript -e 'ObjC.import("CoreGraphics"); var l=ObjC.deepUnwrap(ObjC.castRefToObject($.CGWindowListCopyWindowInfo($.kCGWindowListOptionAll, 0))); var b=l.filter(w=>w.kCGWindowOwnerName=="BetterTouchTool"); "BTT windows: "+b.length+" (onscreen: "+b.filter(w=>w.kCGWindowIsOnscreen).length+")"'
And finally maybe a full spindump for BTT will give more details (again saved to desktop):
The first command returned "BTT windows: 15 (onscreen: 0)". I sent you the log for the second one by email.
The lagging starts as soon as BTT launches. It also occurred to me that another BTT action might be slowing things down. After all, I have dozens, possibly close to a hundred, shortcuts set up. However, the lagging started a while ago after a BTT update, and I'm not sure I added any new shortcuts around that time. I don't have any that constantly monitor a condition in the background, either. Most use BTT's built-in actions. I have a few shortcuts that use AS and JS, but they run and then finish.
I found a potential macOS bug being discussed online that could be related (which seems to be fixed in the 27.2 betas): For apps without on-screen windows, macOS 27.0.x might choose a wrong rendering display if multiple monitors are connected. By default macOS throttles the update rate on the non-mouse / non-focused screen which could explain this.
Does the issue go away if the BTT preferences window is open and focused or if only one screen is connected?
This would also explain the screen recording "fix", as screen recording forces every display update at full speed.
Thanks, you’re a genius. That must be the cause. When I have the configuration window active, the menus are fast. And it really only happens when I have an external monitor connected to my MacBook. As soon as I disconnect it, the menus are fast even with BTT’s invisible windows. We can consider the issue closed, and I’ll just have to wait for macOS 27.2.
