[GH-ISSUE #37] High CPU usage.

gitea-mirror commented

2026-05-05 04:47:53 -06:00

Owner

Originally created by @brechtm on GitHub (Jun 6, 2018).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/37

Originally assigned to: @the0neyouseek on GitHub.

Activity Monitor shows Monitor Control using around 10% CPU time constantly.

I see this behavior with a Samsung SyncMaster 226BW. This monitor does not support querying settings:

$ ddcctl -d 1 -b ?
D: NSScreen #188788209 (1680x1050 0°) 90.00 DPI
I: found 1 external display
I: polling display 1's EDID
I: got edid.name: SyncMaster
I: got edid.serial: HSDP819382
D: action: b: ?
D: querying VCP control: #16 =?
E: No data after 10 tries!
E: DDC send command failed!
E: VCP control #16 (0x10) = current: 0, max: 0

Originally created by @brechtm on GitHub (Jun 6, 2018). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/37 Originally assigned to: @the0neyouseek on GitHub. Activity Monitor shows Monitor Control using around 10% CPU time constantly. I see this behavior with a Samsung SyncMaster 226BW. This monitor does not support querying settings: ``` $ ddcctl -d 1 -b ? D: NSScreen #188788209 (1680x1050 0°) 90.00 DPI I: found 1 external display I: polling display 1's EDID I: got edid.name: SyncMaster I: got edid.serial: HSDP819382 D: action: b: ? D: querying VCP control: #16 =? E: No data after 10 tries! E: DDC send command failed! E: VCP control #16 (0x10) = current: 0, max: 0 ```

gitea-mirror

2026-05-05 04:47:53 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 04:48:00 -06:00

Author

Owner

@the0neyouseek commented on GitHub (Jun 21, 2018):

Hi @brechtm,

Thanks for taking time to test the app. As I work full time I don't have much time to work on this but I'l be sure to take a look at this asap.

Have a nice day.

@the0neyouseek commented on GitHub (Jun 21, 2018): Hi @brechtm, Thanks for taking time to test the app. As I work full time I don't have much time to work on this but I'l be sure to take a look at this asap. Have a nice day.

gitea-mirror commented

2026-05-05 04:48:03 -06:00

Author

Owner

@vogtmh commented on GitHub (Sep 15, 2018):

In case you just need a volume control, you might try out my new version. I've removed all the polling that let to the high cpu usage and haven't noticed any major drawbacks yet.

https://github.com/mavodev-de/ScreenVolume2

However, I don't do a pull request as I'm no real developer and don't wanna mess up the original code. So I thought a fork with another name might be a better solution.

@vogtmh commented on GitHub (Sep 15, 2018): In case you just need a volume control, you might try out my new version. I've removed all the polling that let to the high cpu usage and haven't noticed any major drawbacks yet. https://github.com/mavodev-de/ScreenVolume2 However, I don't do a pull request as I'm no real developer and don't wanna mess up the original code. So I thought a fork with another name might be a better solution.

gitea-mirror commented

2026-05-05 04:48:05 -06:00

Author

Owner

@JoniVR commented on GitHub (May 7, 2019):

Hi @brechtm,
Is this still an issue for you?

@JoniVR commented on GitHub (May 7, 2019): Hi @brechtm, Is this still an issue for you?

gitea-mirror commented

2026-05-05 04:48:08 -06:00

Author

Owner

@brechtm commented on GitHub (May 7, 2019):

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:

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

@brechtm commented on GitHub (May 7, 2019): 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?

gitea-mirror commented

2026-05-05 04:48:10 -06:00

Author

Owner

@JoniVR commented on GitHub (May 7, 2019):

I'm noticing the same, I think I fixed it in a previous version by removing how many times we try to poll the display but it must have slipped back in. I have also noticed some of your other issues you mentioned. I'll try fixing some of these soon. Thanks for the info 👍

@JoniVR commented on GitHub (May 7, 2019): I'm noticing the same, I think I fixed it in a previous version by removing how many times we try to poll the display but it must have slipped back in. I have also noticed some of your other issues you mentioned. I'll try fixing some of these soon. Thanks for the info 👍

gitea-mirror commented

2026-05-05 04:48:11 -06:00

Author

Owner

@reitermarkus commented on GitHub (May 7, 2019):

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.

@reitermarkus commented on GitHub (May 7, 2019): 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.

gitea-mirror commented

2026-05-05 04:48:13 -06:00

Author

Owner

@JoniVR commented on GitHub (May 7, 2019):

@reitermarkus Was this related to the minReplyDelay? Because I seem to remember having the discussion on the ddcctl repo that this might be different based on which GPU vendor you have instead of the monitors (if I understood correctly), so intel integrated graphics would require a longer delay. It would make things a lot easier if that were the case as we wouldn't have to whitelist a large amount of monitors.
I haven't tried whitelisting my own monitor to see if that fixes it for me, I'll try that tomorrow.

@JoniVR commented on GitHub (May 7, 2019): @reitermarkus Was this related to the `minReplyDelay`? Because I seem to remember having the discussion on the ddcctl repo that this might be different based on which GPU vendor you have instead of the monitors (if I understood correctly), so intel integrated graphics would require a longer delay. It would make things a lot easier if that were the case as we wouldn't have to whitelist a large amount of monitors. I haven't tried whitelisting my own monitor to see if that fixes it for me, I'll try that tomorrow.

gitea-mirror commented

2026-05-05 04:48:14 -06:00

Author

Owner

@reitermarkus commented on GitHub (May 8, 2019):

Was this related to the minReplyDelay?

Yes, exactly.

might be different based on which GPU vendor you have

What GPU do you have?

@reitermarkus commented on GitHub (May 8, 2019): > Was this related to the `minReplyDelay`? Yes, exactly. > might be different based on which GPU vendor you have What GPU do you have?

gitea-mirror commented

2026-05-05 04:48:16 -06:00

Author

Owner

@brechtm commented on GitHub (May 8, 2019):

I have a MacBook Pro (Retina, 15-inch, Mid 2014) with integrated graphics (Intel Iris 5200 Pro).

You could also provide an option in the preferences window to toggle the whitelist manually.

@brechtm commented on GitHub (May 8, 2019): I have a MacBook Pro (Retina, 15-inch, Mid 2014) with integrated graphics (Intel Iris 5200 Pro). You could also provide an option in the preferences window to toggle the whitelist manually.

gitea-mirror commented

2026-05-05 04:48:18 -06:00

Author

Owner

@JoniVR commented on GitHub (May 8, 2019):

What GPU do you have?

Intel Integrated Graphics (Iris 1536 MB) - MacBook Pro (Retina, 13-inch, Late 2013)

You could also provide an option in the preferences window to toggle the whitelist manually.
Could be a good idea..

I'm not sure if I like having to whitelist every single monitor manually. A lot of users won't know how to do it themselves so that would probably bring us lots of issues and manual adding. I'm just hoping it depends on GPU Vendor rather than the display itself, but a preferences toggle would be a good option if this isn't the case.

@JoniVR commented on GitHub (May 8, 2019): > What GPU do you have? Intel Integrated Graphics (Iris 1536 MB) - MacBook Pro (Retina, 13-inch, Late 2013) > You could also provide an option in the preferences window to toggle the whitelist manually. Could be a good idea.. I'm not sure if I like having to whitelist every single monitor manually. A lot of users won't know how to do it themselves so that would probably bring us lots of issues and manual adding. I'm just hoping it depends on GPU Vendor rather than the display itself, but a preferences toggle would be a good option if this isn't the case.

gitea-mirror commented

2026-05-05 04:48:21 -06:00

Author

Owner

@JoniVR commented on GitHub (May 8, 2019):

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

@JoniVR commented on GitHub (May 8, 2019): @brechtm You could try using v1.4.0 to see if that solves your issue for now meanwhile.

gitea-mirror commented

2026-05-05 04:48:23 -06:00

Author

Owner

@JoniVR commented on GitHub (May 8, 2019):

Ok so I just tested whitelisting my LG 34UC88-B (also ultrawide), modelnumber 30436 and it froze my system completely by using a longer delay, so it's not the longer delay/whitelisting that will fix it.

I think the high cpu issue/app responsiveness issues are due to trying to poll the display 100 times at initial start to try and read the values. This is also exactly what fixed the unresponsiveness for me when I removed it from the previous version. I've had reports of this being fixed as well on my fork some time ago.

As soon as I change

values = display.ddc?.read(command: command, tries: 100)

to

values = display.ddc?.read(command: command, tries: 1)

inside Utils.swift, the app doesn't use so much CPU and responds instantly at launch for me.

Also, my monitor is still greyed out in the menu, so that's a separate issue too I think.

So I think we've got 3 different issues:

non-Intel GPUs (and possibly some others) might require a different minReplyDelay (that's still a theory and needs testing, see https://github.com/kfix/ddcctl/pull/42)
The high amount of polling is causing slowdowns at launch and unresponsiveness in general for some users, myself included.
~~3. The monitor menu seems to be grayed out for some reason.~~

(I'm using a DisplayPort cable with Intel Iris graphics)

@JoniVR commented on GitHub (May 8, 2019): Ok so I just tested whitelisting my LG 34UC88-B (also ultrawide), modelnumber 30436 and it froze my system completely by using a longer delay, so it's not the longer delay/whitelisting that will fix it. I think the high cpu issue/app responsiveness issues are due to trying to poll the display 100 times at initial start to try and read the values. This is also exactly what fixed the unresponsiveness for me when I removed it from the previous version. I've had reports of this being fixed as well on my fork some time ago. As soon as I change ```swift values = display.ddc?.read(command: command, tries: 100) ``` to ```swift values = display.ddc?.read(command: command, tries: 1) ``` inside `Utils.swift`, the app doesn't use so much CPU and responds instantly at launch for me. Also, my monitor is still greyed out in the menu, so that's a separate issue too I think. ![image](https://user-images.githubusercontent.com/7591717/57371878-3fbd9b80-7194-11e9-8d81-6c257826f057.png) So I think we've got 3 different issues: 1. non-Intel GPUs (and possibly some others) might require a different `minReplyDelay` (that's still a theory and needs testing, see https://github.com/kfix/ddcctl/pull/42) 2. The high amount of polling is causing slowdowns at launch and unresponsiveness in general for some users, myself included. ~3. The monitor menu seems to be grayed out for some reason.~ (I'm using a DisplayPort cable with Intel Iris graphics)

gitea-mirror commented

2026-05-05 04:48:26 -06:00

Author

Owner

@reitermarkus commented on GitHub (May 8, 2019):

Also, my monitor is still greyed out in the menu, so that's a separate issue too I think.

That's because I changed the style to more closely reflect the native volume menu. Maybe we should just not show the display name at all when there is only one monitor in the menu?

@reitermarkus commented on GitHub (May 8, 2019): > Also, my monitor is still greyed out in the menu, so that's a separate issue too I think. That's because I changed the style to more closely reflect the native volume menu. Maybe we should just not show the display name at all when there is only one monitor in the menu?

gitea-mirror commented

2026-05-05 04:48:29 -06:00

Author

Owner

@reitermarkus commented on GitHub (May 8, 2019):

@JoniVR, if you change tries to 1, does it succeed though?

@reitermarkus commented on GitHub (May 8, 2019): @JoniVR, if you change `tries` to `1`, does it succeed though?

gitea-mirror commented

2026-05-05 04:48:32 -06:00

Author

Owner

@JoniVR commented on GitHub (May 8, 2019):

That's because I changed the style to more closely reflect the native volume menu.

Hmmm now that you say it it makes sense. Had me confused though.

Maybe we should just not show the display name at all when there is only one monitor in the menu?

I like it better this way, right now it indicates that it detects the screen.

I think what I meant by it being greyed out was that it was disabled (I'm assuming that's because it's still trying to read the values)

So everytime I launch the app the sliders are disabled and greyed out while trying to read the values.

if you change tries to 1, does it succeed though?

Yup, it works instantly then. I think the polling is just slowing the system down, reading the values never works for my system/display anyways, doesn't matter if it's trying 1 time or 100 times, the only thing it does now is make the app unresponsive and not working properly at launch.

Does trying 100 times make it more reliable for you? Because for me all it does is just slow my whole system down. If reading multiple times does in fact help for some people, we could also just try polling 10 times and if no value can be read just use the previous values?

The original minReplyDelay works on my system too. I'm guessing because it's using integrated graphics and Intel uses a different scale for the delay than the other brands, this would also explain why my system would freeze for a very long time if I use the longer delay (see discussion on ddcctl thread linked earlier).

@JoniVR commented on GitHub (May 8, 2019): > That's because I changed the style to more closely reflect the native volume menu. Hmmm now that you say it it makes sense. Had me confused though. > Maybe we should just not show the display name at all when there is only one monitor in the menu? I like it better this way, right now it indicates that it detects the screen. I think what I meant by it being greyed out was that it was disabled (I'm assuming that's because it's still trying to read the values) ![image](https://user-images.githubusercontent.com/7591717/57402553-d9f30300-71d7-11e9-8e58-7b6c1bcd39f7.png) So everytime I launch the app the sliders are disabled and greyed out while trying to read the values. > if you change `tries` to `1`, does it succeed though? Yup, it works instantly then. I think the polling is just slowing the system down, reading the values never works for my system/display anyways, doesn't matter if it's trying 1 time or 100 times, the only thing it does now is make the app unresponsive and not working properly at launch. Does trying 100 times make it more reliable for you? Because for me all it does is just slow my whole system down. If reading multiple times does in fact help for some people, we could also just try polling 10 times and if no value can be read just use the previous values? The original `minReplyDelay` works on my system too. I'm guessing because it's using integrated graphics and Intel uses a different scale for the delay than the other brands, this would also explain why my system would freeze for a very long time if I use the longer delay (see discussion on ddcctl thread linked earlier).

gitea-mirror commented

2026-05-05 04:48:34 -06:00

Author

Owner

@reitermarkus commented on GitHub (May 8, 2019):

Yup, it works instantly then.

What works instantly? The sliders being available? What I mean is: Does it actually read the value from the display correctly with only 1 try? Or does it only restore it from preferences?

@reitermarkus commented on GitHub (May 8, 2019): > Yup, it works instantly then. What works instantly? The sliders being available? What I mean is: Does it actually read the value from the display correctly with only 1 try? Or does it only restore it from preferences?

gitea-mirror commented

2026-05-05 04:48:37 -06:00

Author

Owner

@JoniVR commented on GitHub (May 8, 2019):

Yup, it works instantly then. I think the polling is just slowing the system down, reading the values never works for my system/display anyways, doesn't matter if it's trying 1 time or 100 times, the only thing it does now is make the app unresponsive and not working properly at launch.

I should've stated this more clearly, my bad - it never succeeds at reading (through ddc). Doesn't matter if it tries once, 100 or 1000 times.

Here are 2 comparison videos, one with 1 try, another with 100 tries. I had to upload to youtube because of Github upload restrictions.
In this example the 100 tries are surprisingly fast, sometimes it takes a lot longer, up to 1-2 minutes. Meanwhile also increasing cpu usage and making me unable to change volume/brightness.

@JoniVR commented on GitHub (May 8, 2019): > Yup, it works instantly then. I think the polling is just slowing the system down, **reading the values never works for my system/display anyways, doesn't matter if it's trying 1 time or 100 times**, the only thing it does now is make the app unresponsive and not working properly at launch. I should've stated this more clearly, my bad - it never succeeds at reading (through ddc). Doesn't matter if it tries once, 100 or 1000 times. Here are 2 comparison videos, one with 1 try, another with 100 tries. I had to upload to youtube because of Github upload restrictions. In this example the 100 tries are surprisingly fast, sometimes it takes a lot longer, up to 1-2 minutes. Meanwhile also increasing cpu usage and making me unable to change volume/brightness. * [polling - 1 try](https://youtu.be/Mzd1Gn2pb5A) * [polling - 100 tries](https://youtu.be/_Kv6sa0KQzY)

gitea-mirror commented

2026-05-05 04:48:39 -06:00

Author

Owner

@reitermarkus commented on GitHub (May 8, 2019):

I added some logging to DDC.swift. Usually I only need 4 tries on average to actually read a value, but occasionally it spikes to > 200 tries.

it never succeeds at reading

Did it ever work (i.e. with ddcctl)?

@reitermarkus commented on GitHub (May 8, 2019): I added some logging to `DDC.swift`. Usually I only need 4 tries on average to actually read a value, but occasionally it spikes to > 200 tries. > it never succeeds at reading Did it ever work (i.e. with `ddcctl`)?

gitea-mirror commented

2026-05-05 04:48:44 -06:00

Author

Owner

@JoniVR commented on GitHub (May 8, 2019):

Did it ever work (i.e. with ddcctl)?

Not as far as I can remember. It never really worked for me. Changing volume, brightness,... always works fine but reading values hasn't ever really worked properly.

I think the 100 tries probably only affect lower end systems, must be too taxing to send 100 requests to the kernel or something (and I'm guessing by all the issues that I'm not alone), it might work for higher end systems but I don't think it's a good solution to be honest.

Also if you usually only take 4 tries, you don't really notice the impact it has as much as unlucky people like me who will have to go through the 100 attempts to have it fail every single time.

Would 10 tries be enough for a good success rate?
I'd suggest we go with 10 tries by default and let the user configure it in the preferences perhaps?

If only Apple were to release a new macbook with a decent keyboard so I could upgrade.. sigh

@JoniVR commented on GitHub (May 8, 2019): > Did it ever work (i.e. with `ddcctl`)? Not as far as I can remember. It never really worked for me. Changing volume, brightness,... always works fine but reading values hasn't ever really worked properly. I think the 100 tries probably only affect lower end systems, must be too taxing to send 100 requests to the kernel or something (and I'm guessing by all the issues that I'm not alone), it might work for higher end systems but I don't think it's a good solution to be honest. Also if you usually only take 4 tries, you don't really notice the impact it has as much as unlucky people like me who will have to go through the 100 attempts to have it fail every single time. Would 10 tries be enough for a good success rate? I'd suggest we go with 10 tries by default and let the user configure it in the preferences perhaps? If only Apple were to release a new macbook with a decent keyboard so I could upgrade.. _sigh_

gitea-mirror commented

2026-05-05 04:48:46 -06:00

Author

Owner

@reitermarkus commented on GitHub (May 8, 2019):

Would 10 tries be enough for a good success rate?

I actually tried this in a loop, but in reality, the first read call always needs more tries it seems.

Reading the brightness always needs about 150 tries, but reading the volume right afterwards usually only needs a single try.

@reitermarkus commented on GitHub (May 8, 2019): > Would 10 tries be enough for a good success rate? I actually tried this in a loop, but in reality, the first `read` call always needs more tries it seems. Reading the brightness always needs about 150 tries, but reading the volume right afterwards usually only needs a single try.

gitea-mirror commented

2026-05-05 04:48:48 -06:00

Author

Owner

@JoniVR commented on GitHub (May 8, 2019):

So what we could do is add it as a configurable option in settings, we could even make an "advanced" tab for stuff like this.

Either just allowing the user to set a specified amount in a textfield or providing a dropdown with "polling modes"
for example:

none
low (5 tries)
normal (10 tries)
high (100 tries)
aggressive (200 tries)

After all we still have the fallback for when reading doesn't work. I know I'd rather have the app actually function than not display a correct initial value 100% of the time (if polling would actually work for me, lol)

@JoniVR commented on GitHub (May 8, 2019): So what we could do is add it as a configurable option in settings, we could even make an "advanced" tab for stuff like this. Either just allowing the user to set a specified amount in a textfield or providing a dropdown with "polling modes" for example: * none * low (5 tries) * normal (10 tries) * high (100 tries) * aggressive (200 tries) After all we still have the fallback for when reading doesn't work. I know I'd rather have the app actually function than not display a correct initial value 100% of the time (if polling would actually work for me, lol)

gitea-mirror commented

2026-05-05 04:48:51 -06:00

Author

Owner

@JoniVR commented on GitHub (May 8, 2019):

@the0neyouseek What's your opinion on this?

@JoniVR commented on GitHub (May 8, 2019): @the0neyouseek What's your opinion on this?

gitea-mirror commented

2026-05-05 04:48:55 -06:00

Author

Owner

@the0neyouseek commented on GitHub (May 8, 2019):

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
    }
  }
}

@the0neyouseek commented on GitHub (May 8, 2019): 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` : ```swift 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 } } } ```

gitea-mirror commented

2026-05-05 04:49:00 -06:00

Author

Owner

@reitermarkus commented on GitHub (May 8, 2019):

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

@reitermarkus commented on GitHub (May 8, 2019): What's weird is that I have just tried adding a test for `DDC.swift`, which succeeds 100 % of the time with 1 try.

gitea-mirror commented

2026-05-05 04:49:02 -06:00

Author

Owner

@brechtm commented on GitHub (May 9, 2019):

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

Could this indicate a bug in MonitorControl's polling? I already found it suspicious that you would need so many tries. Or is DDC that unreliable?

@brechtm commented on GitHub (May 9, 2019): > What's weird is that I have just tried adding a test for `DDC.swift`, which succeeds 100 % of the time with 1 try. Could this indicate a bug in MonitorControl's polling? I already found it suspicious that you would need so many tries. Or is DDC that unreliable?

gitea-mirror commented

2026-05-05 04:49:05 -06:00

Author

Owner

@reitermarkus commented on GitHub (May 9, 2019):

Well, I fixed a race condition in DDC.swift, for me (with the longer 20ms delay) it is 100% reliable now.

@reitermarkus commented on GitHub (May 9, 2019): Well, I fixed a race condition in `DDC.swift`, for me (with the longer 20ms delay) it is 100% reliable now.

gitea-mirror commented

2026-05-05 04:49:07 -06:00

Author

Owner

@JoniVR commented on GitHub (May 9, 2019):

Well, I fixed a race condition in DDC.swift, for me (with the longer 20ms delay) it is 100% reliable now.

100% reliable on first try? That's amazing to hear! I'll try playing around with different delays on my setup soon and try to report to #82 will probably be for tomorrow though.

@JoniVR commented on GitHub (May 9, 2019): > Well, I fixed a race condition in `DDC.swift`, for me (with the longer 20ms delay) it is 100% reliable now. 100% reliable on first try? That's amazing to hear! I'll try playing around with different delays on my setup soon and try to report to [#82](https://github.com/the0neyouseek/MonitorControl/issues/82) will probably be for tomorrow though.

gitea-mirror commented

2026-05-05 04:49:08 -06:00

Author

Owner

@brechtm commented on GitHub (May 10, 2019):

@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.

@brechtm commented on GitHub (May 10, 2019): > @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.

gitea-mirror commented

2026-05-05 04:49:09 -06:00

Author

Owner

@reitermarkus commented on GitHub (May 17, 2019):

@brechtm, can you try with 1.5.2?

@reitermarkus commented on GitHub (May 17, 2019): @brechtm, can you try with 1.5.2?

gitea-mirror commented

2026-05-05 04:49:11 -06:00

Author

Owner

@brechtm commented on GitHub (May 17, 2019):

@brechtm, can you try with 1.5.2?

1.5.2 seems to work similar to 1.4.0. Just a couple of seconds of high CPU usage / pointer jitter after starting MonitorControl, and the brightness slider can be interacted with after that. 👍

@brechtm commented on GitHub (May 17, 2019): > @brechtm, can you try with 1.5.2? 1.5.2 seems to work similar to 1.4.0. Just a couple of seconds of high CPU usage / pointer jitter after starting MonitorControl, and the brightness slider can be interacted with after that. :thumbsup:

gitea-mirror commented

2026-05-05 04:49:13 -06:00

Author

Owner

@JoniVR commented on GitHub (May 18, 2019):

I'm close to being finished on the advanced tab where the user can set a custom polling mode. I'll also add in the whitelist feature but I think we should override it in case the user sets a custom one. Not all settings might work for all setups. Let's hope that fixes it.

@JoniVR commented on GitHub (May 18, 2019): I'm close to being finished on the advanced tab where the user can set a custom polling mode. I'll also add in the whitelist feature but I think we should override it in case the user sets a custom one. Not all settings might work for all setups. Let's hope that fixes it.

gitea-mirror commented

2026-05-05 04:49:14 -06:00

Author

Owner

@JoniVR commented on GitHub (Sep 15, 2019):

People that were having issues with High CPU usage at launch should try v1.7.0 as it now includes the Advanced Preferences Panel that allows you to lower or disable polling. A lower polling setting should reduce CPU usage.

You can also try using a longer delay which may work better with some setups.

For more info, refer to the Wiki.

@JoniVR commented on GitHub (Sep 15, 2019): People that were having issues with High CPU usage at launch should try v1.7.0 as it now includes the Advanced Preferences Panel that allows you to lower or disable polling. A lower polling setting should reduce CPU usage. You can also try using a longer delay which may work better with some setups. For more info, refer to the [Wiki](https://github.com/the0neyouseek/MonitorControl/wiki).

Rows
Columns

[GH-ISSUE #37] High CPU usage. #34