"Auto-detect video call overlays" - 100% CPU, lags, freezing issue

[waydabber]

Hi there,

what does the "Auto-detect video call overlays" feature do (from a technical perspective)? When this is enabled in recent DisplayLink driver versions, some users are reporting 100% CPU usage for the DisplayLink process + stuttering on the DL display when some apps are running. Apparently BetterDisplay (my app) is also known to trigger this issue with the current DisplayLink drivers (indeed, I was able to reproduce the issue).

Right now I advise users to disable the "Auto-detect video call overlays" and/or downgrade the DL driver to v13.x, but if possible, I'd like to offer some sort of workaround in the next BetterDisplay version if possible - if there is anything I can do to improve compatibility, please let me know (unless of course the issue that causes the stuttering and eating up of all CPU resources can be fixed in an upcoming driver version).

I could not pinpoint what exactly causes the problem so far. My suspicion is the app's use of very high-priority NSWindow overlays (at and beyond `CGShieldingWindowLevel` or `kSLSSpaceAbsoluteLevelNotificationCenterAtScreenL ock`) in certain scenarios. Other apps (like Alcove) are mentioned as triggering this issue which probably also use similar techniques. But I am not entirely sure, as I had inconsistent results during testing - sometimes the lag went away, sometimes it came back for no apparent reason and sometimes users reported making the problem go away doing totally unrelated things that sound more like placebo solutions to me (for example downgrading the DL driver and then upgrading again fixes the issue according to some).

Thank you!

[waydabber]

Update: I found an apparent correlation between the 100% DisplayLink CPU usage and the use of `.sharingType = .none` on a high-priority `NSWindow` in a macOS app while "Auto-detect video call overlays" is enabled.

BetterDisplay has an option to "Prevent overlays from affecting screenshots and screen recordings" - when this is enabled and BetterDisplay is configured to use overlay effects, the app uses `.sharingType = .none` on overlay NSWindow objects. This somehow seems to trigger the 100% CPU DisplayLink driver problem (- most of the times but strangely not always).

In upcoming app versions I'll set this setting to disabled by default - hopefully this will improve things. I post this info here as it might help the DisplayLink team to double down on this issue or figure out the root cause as probably other apps are affected too (configuring a high priority window with `.sharingType = .none` is normal and should not cause an issue like this).

[Szymon]

Hi waydabber,

Microsoft Teams on macOS uses the NSWindow object with the property .sharingType = .none for screen sharing control. As a result, these windows are not visible on external DisplayLink screens. This become a hot issue in the beginning of this year. To address this DisplayLink implemented a workaround that detects such objects and makes them visible. However, this approach comes with a trade-off: reduced performance.

Ideally, Microsoft would resolve this issue in Teams for macOS, but so far, no fix has been provided. Apple explicitly recommends using SCContentFilter to exclude UI elements that are not intended for streaming, which seems like the proper solution.

Regards,
Szymon

[waydabber]

Thanks Szymon for the update on this. Hopefully Microsoft will indeed fix this.

I'll have the relevant setting disabled in the next app version by default so BetterDisplay does not interfere.

Is there any way an app can reliably detect whether a (virtual) display was created by DisplayLink? It would be great to make sure everything is configured properly without user intervention.

[Szymon]

Just delivered DisplayLinkManager 15.0 should mitigate this problem. See downloads page:
https://www.synaptics.com/products/d...ownloads/macos

Regards,
Szymon