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

Very slow #24

Open
mihar opened this issue Jul 13, 2020 · 18 comments
Open

Very slow #24

mihar opened this issue Jul 13, 2020 · 18 comments
Assignees
Labels
bug Something isn't working enhancement New feature or request

Comments

@mihar
Copy link

mihar commented Jul 13, 2020

Not as much a bug as I'm just curious if it's just my computer or is this normal. But triggering the hints takes about 2 seconds to appear. That is too slow to make it usable.

@ycanerol
Copy link

Same here, the delay makes it unusable. For reference I'm on macOS 10.15.5, installed via homebrew.

@viettrungphan
Copy link
Contributor

@mihar thanks for letting me know, we are finding solutions for it. You can temporarily restart your MAC to improve the speed.

@viettrungphan viettrungphan self-assigned this Jul 23, 2020
@viettrungphan viettrungphan added bug Something isn't working enhancement New feature or request labels Jul 23, 2020
@lshigw
Copy link

lshigw commented Dec 12, 2020

Love this app. Just have the same lag issue here on my Apple Silicon MacBook Pro 8GB. Looking forward to the next version!

@ashtonian
Copy link

Any chance we could see the code to fix this? This is unfortunately an unusable app in current state.

@viettrungphan
Copy link
Contributor

As my tested, we can't do anything, the app simple using accessibility api to query UI elements, the same code, the same UI but the query time varies between test. One more thing: I guess API using synchronous task on Main thread, I try dispatch async to query but not improve at all.

@ashtonian
Copy link

It would be great to contribute to this directly. I suspect (without any clue how the code works so with a grain of salt) there are lower level apis, and a way to cache the results given some assumptions, especially around some some specific OS X features that are used commonly that have semi static elements like the dock/menu bar. There may also be a way to make some assumptions for many common apps, although not ideal it could theoretically be done and may be easier to maintain. Are you dispatching async tasks in parallel? what apis are you using to query the ui elements?

@viettrungphan
Copy link
Contributor

@ashtonian Can you help me do some small test? When you are facing slow on any application, go to System Preferences and Find for Voice Control. Enable it then focus on the app that you feeling slow, then active Voice control by say "Show numbers" then compare the speed of native Mac Voice Control with VimMotion.

@viettrungphan
Copy link
Contributor

viettrungphan commented Feb 3, 2021

Basically app recursive call AXUIElementCopyAttributeValues to query all UIElements then filter commons UI "Label, Button, Text Field, Button, Image....". I don't want goes with cache solution because UI constantly update make cache outdate easily , StatusBar already preload and cache by default it automatically refresh when app detect new app open or close.

@ashtonian
Copy link

When I use show numbers in apps its pretty responsive, the real test though would be the desktop which is what I want to use vimmotion for and it seems like the voice controls don't account for that. Can you share a snippet of calling that accessibility api? I'd like to play with it if possible.

@viettrungphan
Copy link
Contributor

viettrungphan commented Feb 4, 2021

Did you make the test when you facing slow on VimMotion? Problem may because your desktop don't have microphone huh?
This func using to query array of child element. The UI not simple one level, it have many child of child so you need for loop and recursive call to get all UIElements, the break point for recursive func is "nil" mean you reach leaf node of UI.

func subElements(element: AXUIElement) -> [AXUIElement]? { 
        var subElements: CFArray?
        var count: CFIndex = 0
        var error: AXError
        error = AXUIElementGetAttributeValueCount(element, kAXChildrenAttribute as CFString, &count)
        if error != .success { return nil }
        error = AXUIElementCopyAttributeValues(element, kAXChildrenAttribute as CFString, 0, count, &subElements)
        if error != .success { return nil }
        return subElements as? [AXUIElement]
    }

But you need the app root element first, get it by find App p_id

func element(from pID: pid_t) -> AXUIElement {
        return AXUIElementCreateApplication(pID)
}

For example get Dock process Id from Bundle Id:

func dockElements() -> AXUIElement? {
        guard let dock = NSRunningApplication.runningApplications(withBundleIdentifier: "com.apple.dock").first else {
            return nil
        }
        let dockPID = dock.processIdentifier
        return AXUtilities.element(from: dockPID)
    }

@italo-amaya-utec
Copy link

You can add options to exclude menu bar icons as well as a option to only query the api for the ui elements of the current app. Caching will also improve speed

@viettrungphan
Copy link
Contributor

Menu prequery and cached in the background, the cache refesh when new app open or closed app.

@tolgraven
Copy link

tolgraven commented Dec 10, 2021

Nowhere near 2 seconds on my 16" M1 but still too sluggish to be something I'd end up using much :/

Some ideas:
-Allow filtering what elements to look for (good idea either way - for example I see no point in being able to select within a website, I use Vimari for that...)
-Chunk search and populate elements as they come - would also mean menu bar appearing instantly.
-Parallellize queries.
-Optional mode where it updates in background every few seconds + after each time VimMotion is used or fg app switched.

@DylanOpet
Copy link

Would love if it were faster similar to Vimac. This finds much more than Vimac, so this is amazing other than the speed.

@yecine06
Copy link

same as @DylanOpet on my mac it's very very slow sometime it freezes and never display the hint shorcuts

@mrsnakeoil
Copy link

I am experiencing the same delay. The workflow is amazing and has so much promise, but the delay is too much for me to use it.

If you need any testing or help on the topic have a M1 MacBook Air here - happy to run a clean OS installation etc.

@eugenesvk
Copy link

Maybe it could help if you could have an option to ignore the menubar and the dock bar, there are other alternatives to keyboard-target those, these would reduce the number of elements you need to parse

@sjrothfuss
Copy link

+1 on the delay, takes ~2s for hints to appear after using shortcut. M2 Mac Mini, macOS Sonoma 14.2, Vim Motion version 1.2.3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests