search

mjrusso / scoot

Keyboard-driven MacOS cursor actuator
BSD 3-Clause "New" or "Revised" License
333 stars 14 forks source link

Different grid load times depending on which display is currently focused #25

Closed B1T3X closed 2 years ago

B1T3X commented 2 years ago

This issue might be a bit tricky to debug, but is definitely something I think extremely limits the use of Scoot.

I'm using 2 monitors - the build in Mac display and an external monitor When launching the grid mode while focused on the external monitor, the grid loads up on both displays almost instantaneously. When launching it when focused on the build-in display, though, it can take up to 7 seconds at times to render the grid on both displays.

Steps to reproduce:

  1. Click anywhere on the external display
  2. Launch Scoot's grid mode with keyboard shortcut
  3. Grid loads almost instantaneously on both displays
  4. Press Esc to close grid mode
  5. Click anywhere on the built-in display
  6. Launch Scoot's grind mode with keyboard shortcut
  7. Grid takes a while to render, making Scoot impractical to use

Scoot version: 0.12 (1) MacOS version: 12.2.1 Model: MacBook Pro 13-inch 2017, 2.3GHz i5 & 16GB RAM

Thanks, Orel

mjrusso commented 2 years ago

Hi Orel,

Currently, when Scoot is activated, it traverses the accessibility tree for the frontmost/focused application and builds the data structure used for element-based navigation, regardless of which navigation mode is requested. The thinking here was that once Scoot is on screen, you could swap between (for example) grid-based nav and element-based nav, without any delay. (This implementation leaves a lot of room for improvement... if you're using grid-based or freestyle nav, these modes should come up instantly. Personally it doesn't bother me too much, because a) I mostly use element-based nav these days, and b) I haven't come across any apps that take longer than a second or so to traverse their accessibility tree, but I do think this should be fixed.)

All that being said, it's likely whatever app you're focusing when you're clicking on the built-in display. Just to be sure, can you try focusing a different app when you click on the built-in display before invoking Scoot (and repeating with a few different apps) and let me know what you see? You can also attach logs: open Console.app, filter for subsystem:com.mjrusso.Scoot, and start recording.

B1T3X commented 2 years ago

Hi Orel,

Currently, when Scoot is activated, it traverses the accessibility tree for the frontmost/focused application and builds the data structure used for element-based navigation, regardless of which navigation mode is requested. The thinking here was that once Scoot is on screen, you could swap between (for example) grid-based nav and element-based nav, without any delay. (This implementation leaves a lot of room for improvement... if you're using grid-based or freestyle nav, these modes should come up instantly. Personally it doesn't bother me too much, because a) I mostly use element-based nav these days, and b) I haven't come across any apps that take longer than a second or so to traverse their accessibility tree, but I do think this should be fixed.)

All that being said, it's likely whatever app you're focusing when you're clicking on the built-in display. Just to be sure, can you try focusing a different app when you click on the built-in display before invoking Scoot (and repeating with a few different apps) and let me know what you see? You can also attach logs: open Console.app, filter for subsystem:com.mjrusso.Scoot, and start recording.

Yup, seems to have been the problem. Electron apps are a b*tch. Thanks! Orel

mjrusso commented 2 years ago

Filed #26 as a follow-up.