Listening to all mouse movements is a performance concern

[ShlomoCode]

In regards to fast mouse movements: We could make a dead zone around the size and position of the dock, and only start listening once it is in that area. I have thought about implementing that, I don't think it would be too difficult.

Originally posted by @ejbills in https://github.com/ejbills/DockDoor/issues/62#issuecomment-2207710289

@ejbills Can you elaborate on that a bit more?

[ejbills]

Using the Dock Util methods, we can approximate an area and location of the dock. Using this, we can immediately rule out wasted icon frame computations based on the mouse being within our approximated dock area.

[ShlomoCode]

Oh, I thought macOS had an option to only listen for movements on a certain element or something, and I didn't understand why I can't find it... 😆

[ejbills]

Me too, which is why I used that verbiage in my original comment. Is it really not possible? Either way, whether we can make the app only ‘track’ the mouse in that zone or use it to prevent useless dock frame calculations, it should hopefully result in much less CPU usage when the mouse is moved quickly.

[ShlomoCode]

@ejbills I found 2 huge breakthroughs, stay tuned!

[ejbills]

@ejbills I found 2 huge breakthroughs, stay tuned!

You have my interest!

[ejbills]

@ShlomoCode

I hope there won't be too many conflicts with the refactor I'm cooking 😆

We should probably discuss! Mind sharing more details on what you're cooking up? Or is the refactor something unrelated? We can merge our changes on top of whatever you are doing without much hassle, don't worry!

[ShlomoCode]

I researched the Dock's accessibility information and found 2 things:

• We can find the application under the mouse using kAXSelectedChildrenAttribute, instead of our own calculation based of the mouse position. As a side effect this solve https://github.com/ejbills/DockDoor/issues/19 as we are now using macOS's determination of what is considered "selected".
• It is possible to reach the bundle URL of a certain dock item element using kAXURLAttribute. From there you can get the bundle identifier and use it to find the application windows in a completely accurate way according to the bundle identifier, instead of the current heuristic (although we will have to implement a fallback for some particular applications that do not have a bundle identifier, I know about scrcpy and the Android Studio emulator)

I created a POC for the 2 points and it works. You can see it (messy!) at https://github.com/ShlomoCode/DockDoor/tree/poc.

p.s. I'd rather you not pick it into your own commit.

[ShlomoCode]

Mind sharing more details on what you're cooking up? Or is the refactor something unrelated?

In fact the refactor was mainly on the assumption that we no longer need the title heuristic. But I realized that this assumption is not correct (because of exceptions like scrcpy and the Android Studio emulator), so most of the refactor drop at the moment.

[ejbills]

I researched the Dock's accessibility information and found 2 things:

• We can find the application under the mouse using kAXSelectedChildrenAttribute, instead of our own calculation based of the mouse position.

Oh wow, I'm assuming this will lead to a significant reduction in the amount of computations we need to do?

As a side effect this solve Dock Previews Do Not Activate When Cursor Is Below Icon #19 as we are now using macOS's determination of what is considered "selected".

• It is possible to reach the bundle URL of a certain dock item element using kAXURLAttribute. From there you can get the bundle identifier and use it to find the application windows in a completely accurate way according to the bundle identifier, instead of the current heuristic (although we will have to implement a fallback for some particular applications that do not have a bundle identifier, I know about scrcpy and the Android Studio emulator)

This is excellent, and will save us even MORE work that will continue to optimize DockDoor.

I created a POC for the 2 points and it works. You can see it (messy!) at https://github.com/ShlomoCode/DockDoor/tree/poc.

p.s. I'd rather you not pick it into your own commit.

I will check it out once you have it polished. But just based on what you're mentioning, I am very excited! Thank you for your continued contributions to DockDoor, you are integral to its success. Also, this made me cry inside given how much time it took to get the dock hover detection workinf 😆

[ShlomoCode]

Oh wow, I'm assuming this will lead to a significant reduction in the amount of computations we need to do?

Hmmm... I expected it, but in a superficial measurement I didn't see a significant difference. I still need to research this, i suspect it has to do with other things I changed in my POC. BTW, I found out the information using the Accessibility Inspector

[ShlomoCode]

@ejbills Update: I made a working POC for the Dock peeking without .mouseMoved listener (using kAXSelectedChildrenChangedNotification observer on the dock items list)! We may need to listen to the mouse while the preview window is open to detect exiting it, but we certainly don't need to continuously listen to all mouse movements.

[ShlomoCode]

I was able to completely get rid of mouse event listening. This means that when not over the Dock, the CPU usage is 0%