Relatively high CPU usage (1-2% during every mouse event)

[chrisballinger]

Every mouse event causes the EventTapCallback to be called, which over time results in a constant 1-2% CPU usage.

I did a basic time profile and found that the main culprit is calling [NSEvent eventWithCGEvent:eventRef], which seems extremely slow for something that I assumed would be "toll-free". There are a few things I'm going to try to reduce CPU usage in the callback, but I was wondering if you had a preferred approach.

[chrisballinger]

After further investigation I think this is unavoidable because I don't think it's possible to distinguish between mouse gesture events and touchbar events without first creating the NSEvent.

[niw]

@chrisballinger Thank you for your investigation, I didn't realize that eventWithCGEvent: costs that much. Actually, after disassemble NSEvent implementation, it does more than I expected. Technically, scan all possible event types and create touches synchronously upfront, which is not deferring at all. I think we can use CGEvent directly with some private values to mitigate this call.

[niw]

Created #15 for testing.
The change removes all eventWithCGEvent: call from non Touch Bar related gesture events.
However, as I tested, probably because of amount of events we anyways need to observe, it still costs some CPU usage.
Wondering if this patch is worth enough or not... 🤔

[chrisballinger]

I made a very similar patch on a branch that I threw away :) The hard part will be figuring out how to filter mouse gestures vs touchpad gestures from some private CGEvent API without first converting to NSEvent, because that would eliminate most of the noise. Even if you still have to eventually convert the touchpad gestures to NSEvent, being able to efficiently ignore the extraneous trackpad input would eliminate the vast majority of CPU usage since most of the time I'm not using the touchbar.

[niw]

@chrisballinger Yeah, that part, differentiating events from Touch Bar or normal multi touch device, requires some undocumented API usages. If you can test this branch and see some benefits, I’m going to merge this.

[ghazel]

I found another potential solution; watch IOHID for Touch Bar events, and only enable CGEventTap for a brief period after. As long as the CGEventTap was created before the event, it does seem to catch the keydown event.

Proof of concept: https://gist.github.com/ghazel/e2e0f2644f816cb4167021a2e0566357

[niw]

@ghazel Awesome. This is good hack. For sure, using IOKit would be a possible solution, not only for this but also other issues such as #4. Let me test your proof of concept and see the results!

[gch1p]

Hi! Have you tried the proposed IOKit solution?

[niw]

@gch1p Yeah, I tested once and tried to use it, however recently I was a little bit busy and couldn’t have time to work on it. I will give another work soon.

[koynoyno]

@niw Just found this app and it's extremely useful! However, I just can't use it while this bug is active, I prefer more battery life than constant loading on CPU. Would it be possible to fix this issue?

[DennisSchiefer]

I can second that. If @niw is currently busy, @ghazel would you be up to trying to add this to HapticKey?