Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macOs Mojave noticably delay #411

Closed
TheKnarf opened this issue Apr 16, 2020 · 5 comments
Closed

macOs Mojave noticably delay #411

TheKnarf opened this issue Apr 16, 2020 · 5 comments

Comments

@TheKnarf
Copy link

For us to be able to understand the issue you're having you need to follow this template. Please make sure there isn't already an issue for the bug you've found, otherwise it'll just take more resources, which means less time for us to actually fix bugs. Thanks for reporting!

Describe the bug

First time testing out ActivityWatch, installed it using brew cask install activitywatch. After installing it I'm noticing a bunch of delays when doing all kinds of stuff. Writing in chrome stutters. Switching windows sometimes have a small (a few hundred milliseconds? at least enough to be noticeable and annoying) delays before it gets active.

I can't do anything but assume that ActivityWatch is the one imposing these delays / stutters as it started happening right as I installed and started the app.

To Reproduce

Happening on a new install after starting it and giving it accessibility access.

Environment

  • ActivityWatch version: 0.9.2
  • OS: macOs Mojave 10.14.6
@TheKnarf
Copy link
Author

TheKnarf commented Apr 16, 2020

It's deffinitly a problem aw-windows-watcher as the problems go away when I disable that process from the tray icon, but when I turn it on the problems come back.

The logs for aw-windows-watcher doesn't say anything:

2020-04-16 22:49:08 [INFO ]: aw-watcher-window started  (aw_watcher_window.main:40)
2020-04-16 22:49:09 [INFO ]: Connection to aw-server established by aw-watcher-window  (aw_client.client:348)

This problem effectively makes my mac / activitywatch unusable for my use.

@TheKnarf
Copy link
Author

Without actually having done any profiling, just looking quickly at the code, I do imagine if the following line isn't run async that it might create some problems:

https://github.com/ActivityWatch/aw-watcher-window/blob/cea4bf048ed9e4af66445bff5015e38c510ec892/aw_watcher_window/macos.py#L7

@TheKnarf
Copy link
Author

TheKnarf commented Apr 16, 2020

This stackoverflow answer hints to that it might be possible to use the Carbon Accessibility API to ask for current active window title. That might be more efficient than running osascript.

This other StackOverflow answer also shows that the ASOC library allows you to call into applescript directly. But it would be better to just use the accessibility API if possible.

@TheKnarf
Copy link
Author

Decompiling printAppTitle.scpt by downloading it and running osadecompile printAppTitle.scpt reveals that the code is as following:

global frontApp, frontAppName, windowTitle

set windowTitle to ""
tell application "System Events"
	set frontApp to first application process whose frontmost is true
	set frontAppName to name of frontApp
	tell process frontAppName
		try
			tell (1st window whose value of attribute "AXMain" is true)
				set windowTitle to value of attribute "AXTitle"
			end tell
		end try
	end tell
end tell

do shell script "echo " & "\"\\\"" & frontAppName & "\\\",\\\"" & windowTitle & "\\\"\""

I do wonder if this is the thing that slows it down, or if the problem is elsewhere. It would also be nice if one could deliver the same functionality without having to refer to application "System Events" like that, as I got a bunch of popups when first installing the program where it wanted to control "System Events".

@xylix
Copy link
Contributor

xylix commented Apr 16, 2020

There's significant work on moving away from the AppleScript solution at ActivityWatch/aw-watcher-window#40 . It does require some significant changes though, partially becase of the problems getting both app name and window title, and partially because of problems getting the native accessibility API access.

Your performance issues probably aren't because of that though, it's mostly because of the system events spam I think. More details here, #380 and I recommend we move future discussion there as well will be closing this issue for now, to keep most information about this bug in one place. There are some suggested workaround there in the latest comments, I recommend you look through them.

Your report did help me narrow it down that this is surely happening for brew installs. I also have not been able to reproduce on Catalina, but we have had multiple reports of this problem on Mojave. Work is being done on actually giving a sensible error on these cases /

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants