Bug: Reports of PA using a lot of Battery on macOS

[casaout]

We need to observe resource/battery usage on macOS, as one user reported it being the second most battery-draining app (after the browser).

I checked on Windows, where it accounts for <2% of battery use, which is okay I think.

[casaout]

@royru shared his battery usage - (when discarding the surprisingly high Activity Monitor), it seems to also have quite an impact

[casaout]

One idea could be that the taskbar creates a new process every time the window is opened.

@royru observed battery usage for a few days with/without taskbar enabled and (besides occasional spikes when actively used), he didn't see any significant differences in terms of energy impact / battery usage

[casaout]

We have one more report regarding battery use, on the following devices:

• macOS 26.0.1 and Macbook Pro (M1 Pro, 8 cores) -- running AIRbar
• macOS 15.4.1 and Macbook Pro (M4 Max) -- running PA-SWELL (newest)
• macOS 26.0.1 and MacBook Pro 2023 -- running PA-SWELL (newest)
• macOS 15.6 and Macbook Air 2020 (M1) -- running AIRbar
• macOS 15.6.1 and MacBook Air, M3, 2024 -- running AIRbar
• macos 15.6.1 and MacBook Pro with M2 Pro Chip -- running PA
• macos 15.7.5 and MacBook Pro (Intel i9, 2019) -- running AIRbar

Where it works:

• Roy?
• Isabelle: macOS 15.2 and Macbook Pro (M1) -- running AIRbar
• Malte: macOS 26.1 and Macbook Pro (M1) -- running AIRbar
• Tarek: macOS 14.4.1 and macbook pro (M1) - running AIRbar

Thoughts/Hypotheses:

• Current hypothesis is that it's related to this bug: High battery usage and multiple threads on macOS 15+ when polling window information sindresorhus/get-windows#195 that is used in PA.WindowsActivityTracker where it creates several main processes (due to an exception/error)
• Also it seems that it is creating lots of main processes. One user reported a new process might be created with each re-login (maybe the "pause" and "continue/restart" monitoring has an issue?
• Another idea could be that the child process that is created when polling for window title information leads to an error
• (prio 2) checkout alternative approach from ActivityWatch

First steps

• first, can we replicate it in a simple nodejs-script (without running the entire PA-electorn app)?
• update get-windows package: Update get-windows package in WindowsActivityTracker #457 (likely not fixed, as nothing in the changelog seems to suggest that)
• fork the get-windows library and improve the logging:
  • make a try-catch around L38 where the child process is spawn and log the error
  • before and after calling the function in the library, we could log the timestamp to see how long the call takes (e.g. if it's blocked somewhere or not even finished in some cases)
  • ask ChatGPT to make other improvements in the macos.js script and the Swift code

[casaout]

Another user confirmed that lots of main and replayd processes are running - the latter one being related to screen recording (i.e. likely for accessing the window titles):

The replayd-bug might be caused by to many parallel main processes:

• https://issues.chromium.org/issues/379347944
• https://apple.stackexchange.com/questions/464608/usr-libexec-replayd-high-cpu-usage-all-the-time-around-90#comment714382_471847

[casaout]

Steps to test:

• review code fix: only allow one activeWindow process to spawn at a time PA.WindowsActivityTracker#37
• run on macs to see if problem is fixed
• validate that tracking is still complete