MonitorControl: High CPU usage.

@brechtm You could try using v1.4.0 to see if that solves your issue for now meanwhile.

v1.4.0 seems much better behaved indeed. There’s only mouse pointer stutter for a couple of seconds after starting MonitorControl. Ideally, applications shouldn’t cause any pointer stutter at all, of course, but this is already much better.

What’s weird is that I have just tried adding a test for DDC.swift, which succeeds 100 % of the time with 1 try.

I like the idea of having an advanced tab in the settings because it may require tweaking for different display.

I know that I don’t have this problem at all on mine (Asus PB278QR) and values read correctly everytime.

Maybe we could use the system of whitelisted display to have default settings values for the ones we already know works.

Something like adding case specificPollingMode(mode: PollingMode) to our enum WhitelistReason :

enum PollingMode {
  case none
  case minimal
  case normal
  case heavy
  case custom(value: Int)

  var value: Int {
    switch self {
      case .none:
        return 0
      case .minimal:
        return 5
      case .normal:
        return 10
      case .heavy:
        return 100
      case .custom(let val):
        return val
    }
  }
}

Yes, I reverted the longer delay fix and added a whitelist for displays which need it, so the Samsung SyncMaster 226BW will have to be added to the whitelist probably.

Thanks for the heads up, @JoniVR!

Unfortunately, this is still an issue. I just tested with MonitorControl v1.5.0. After startup, MonitorControl’s CPU usage settles to around 2% and mouse pointer movement is jittery. After a while, CPU usage drops to 0% and pointer movement is smooth again. On closing and restarting MonitorControl, the same thing happens (pointer movement is jittery again initially).

Some more detailed observations:

• everything in the drop down menu except for “Preferences” and “Quit” is greyed out
• there is a volume sider as well even though this monitor has no speakers (but it’s connected with a HDMI-DVI cable)
• right after starting MonitorControl, the brightness/volume sliders are disabled (not possible to drag the slider)
• after some 5-60 seconds (this changes a lot from one run to another), the sliders are enabled (the line becomes a little bit darker)
• sometimes the volume slider becomes active first, other times the brightness slider is first - there can be quite some time between their activation (30+ seconds)
• CPU usage drops to 0% and pointer movement become smooth again as soon as both sliders are active (independent of which slider becomes active first)
• enabling the contrast slider make pointer movement unbearably slow - once the slider is enabled, it seems to work fine however

Some questions that come to mind:

1. Why can it take so long for the sliders to become enabled (polling?). Can the polling be disabled?
2. Would it be possible to disable the volume slider (and associated polling) in the preferences window?
3. I noticed that checking/unchecking “Enabled” in Preferences/Display seems to have no effect. Is this normal?