Reduce eventWithCGEvent: call.

[niw]

• Add new delegate callback that can take CGEvent directly without converting to NSEvent
• Check if the event is for Touch Bar or not by using undocumented kCGEventFieldTouchContextID before converting NSEvent to reduce eventWithCGEvent: call.

[chrisballinger]

Typo -> kCGEventFieldTouchContextID

[niw]

Oops!

[chrisballinger]

I tested this branch briefly in the profiler. The good news:

• There's no more eventWithCGEvent bottleneck
• There are no visible bottlenecks in the profiler at all coming from the HapticKey application code

The bad news:

• Average CPU usage of moving the mouse around remains the same, around 2%
• [NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] is now the culprit. I'm not sure if there's any way to optimize this further without bypassing AppKit.

To run these tests I open up Haptic Key and repeatedly tap or move the mouse cursor in circular patterns while running the Time Profiler in Instruments, or keep an eye on CPU Usage in Activity Monitor.

  25  872.0  HapticKey (88322) :0
  24 libdyld.dylib 822.0  start
  23 AppKit 822.0  NSApplicationMain
  22 AppKit 794.0  -[NSApplication run]
  21 AppKit 793.0  -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
  20 AppKit 793.0  _DPSNextEvent
  19 HIToolbox 701.0  _BlockUntilNextEventMatchingListInModeWithFilter
  18 HIToolbox 701.0  ReceiveNextEventCommon
  17 HIToolbox 686.0  RunCurrentEventLoopInMode
  16 CoreFoundation 649.0  CFRunLoopRunSpecific
  15 CoreFoundation 616.0  __CFRunLoopRun
  14 CoreFoundation 315.0  __CFRunLoopDoSource1
  13 CoreFoundation 311.0  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__
  12 CoreFoundation 299.0  __CFMachPortPerform
  11 SkyLight 268.0  eventTapMessageHandler
  10 SkyLight 267.0  _XPostEventTapData
   9 SkyLight 192.0  processEventTapData
   8 SkyLight 88.0  postEventsWithStyle
   7 SkyLight 41.0  CGSEncodeEventRecord
   6 SkyLight 30.0  event_create_data_with_options(__CFAllocator const*, __CGEvent*, SLEventCreateDataOptions, unsigned int)
   5 libc++abi.dylib 5.0  operator new(unsigned long)
   4 libsystem_malloc.dylib 5.0  malloc
   3 libsystem_malloc.dylib 5.0  malloc_zone_malloc
   2 libsystem_malloc.dylib 5.0  szone_malloc_should_clear
   1 libsystem_malloc.dylib 3.0  small_malloc_from_free_list
   0 libsystem_malloc.dylib 2.0  small_free_list_remove_ptr_no_clear

[niw]

True. As I separate event tap to the own runloop on the different thread than NSApplication’s runloop, then see cleaner call tree, but still most of time is spent to process CGEvent itself, not application code. It still uses 2% ~ 3% cpu on MacBook Pro depends on how frequently gestures are introduced on the multitouch devices like track pad.

As long as we’re using CGEventTap to listen gesture events, it can’t be differentiate between multi touch gestures and Touch Bar gestures so anyways the tap gets all unnecessary events and spends some time to process them.

Probably there are yet another solution to listen only events on Touch Bar, but I didn’t investigate yet.

[MoNTE48]

Will it ever be merged? Or is this app is obsolete?

[rafael-b-g]

Any updates? I really want to use this app, but if it costs battery life then I prefer the battery.