I just bought myself a Razer Naga Trinity mouse with 12 extra buttons on the side to use for macros and Keyboard Maestro. In the mouse driver (Razer Synapse, officially supporting Mac but reports of some instability) I assigned the relevant mouse buttons to keyboard keys, and made them into triggers in KM. I got it to work mostly the way I wanted, but then I noticed the Keyboard Maestro symbol in the OS X menu bar started to flicker when moving the mouse, I checked the Activity Monitor, and whenever I moved the mouse (without clicking anything) the resources for KB went up to 50 %. When using the touchpad to move the cursor (with the mouse still connected) nothing like this happened. I have now completely uninstalled the mouse driver, but the problem remains when the mouse is connected.
Any solution? Multi button mouses are perfect to use with KM. Im working on a thesis with a deadline soon, and the mouse will help a lot so I hope there is a way to fix this. Im a little hesitant of using it when it makes KM using so much resources.
Here is my screen recording showing this (Note: When moving the cursor in the last part, I used the touchpad.): https://youtu.be/9cRvzFaz4jM
Check if any macros are being triggered (either with the Engine.log file (Help ➤ Open Logs Folder) or with the Assistance window).
Other than that, it may be that the mouse is sending a continuous stream of USB HID events, which can affect performance, but that should not cause the “Keyboard Maestro symbol … to flicker”
Thank you for your reply peternlewis. This is the situation:
I managed to do something that helped reduce the CPU load a lot (for KM engine, Skim is still at 35% when cursor moves while activated), but it is still high.
After trying the mouse with another Mac with keyboard Maestro running, the problem only appeared when I loaded my macros into the other Mac, and then it was the same. So I realised it had to be some of the macros causing the problems with the mouse. As mentioned, I had used only hotkeys for triggering my macros, but I had made a test macro that didn't have any actions to it, just a usb device key trigger, assigned to a button on my Razer Naga Trinity mouse. Removing this made the Keyboard Maestro Engine CPU load when moving cursor (just on the desktop with KM in background) go down from 50% til 14%, but still a lot more than my other traditional Microsoft Intellimouse that sits at 3%.
I checked the Engine.log file. My mouse movement does not trigger any macros.
So here is the thing. My macros, except for controlling mission control and some scrolling, is all tied up with Skim, my PDF reader. I use KM to more easily annotate and control the PDF reader. It is all simple macros, like move mouse, click current mouse position, find image, keystroke etc. All triggered by normal hotkeys. The buttons on my mouse has been changed in the mouse driver to simulate keyboard numbers with modifiers, and I use this in KM with hotkeys for triggers. So I don't understand what is causing problems.
When moving cursor over a selected Skim PDF file with KM Engine running in the background the SKIM CPU load goes still up to 35% vs 9% with my traditional MS mouse... Maybe it is some USB HID events you mention. Any advice for looking at this?
Again, thank you
I now checked Skim with Keyboard Maestro Engine shut down, the CPU issues remain. Also checked Preview and Safari, also there, huge difference in CPU usage when moving my new mouse vs old. Seems like it has less to do with KM then..
This makes sense, and gels with the previous comment:
I am fairly confident the mouse is sending lots of HID USB packets when it is moving. This is causing a base CPU load on the Mac of about 9% just ignoring all those packets.
When Keyboard Maestro has any USB Device Key triggered macros, it is watching those packets, and thus adding another 26% CPU usage while it ignores the packets (it takes more work for Keyboard Maestro to ignore them than the system to ignore them, so it makes sense that it uses even more CPU).
The solution I'm afraid is for the mouse firmware to be adjusted to properly throttle the number/size of the packets being sent.