Amethyst bogs with "unresponsive" apps

[stylerw]

I've got a few applications which, when doing heavy computes (like R, a statistics app, or Praat, a speech analysis app), will go "unresponsive", displaying as such in the in the Force Quit menu, with broken UI, even when they're still working fine in the background. During this time, you can't even manually move the window. When they finish the compute, they spring back to being good citizens.

The problem is that when Amethyst is running and these apps do this, it completely bogs down trying to move this un-movable, unresponsive window. Even hovering the menu icon beachballs, new windows take 30-45 seconds to tile or switch positions when requested to. The only solution is to kill Amethyst or disable tiling for the duration of these "misbehaved" computes.

I know we're dealing with another App's misbehavior, but it might be handy to ask Amethyst to stop trying to move a given window after N attempts, or just "Float" unresponsive windows, or something like that. It's a regular frustration for me, one of few I have with Amethyst :)

Trello Card

[ianyh]

Yeah, this is a known problem. Everything is done more or less serially so if we hit a snag it slows down everything. I haven't figured out a good solution for it. Tiling windows, for example, has the potential for some really weird interactions if you can tile everything but the windows from the unresponsive application. Other things like moving focus could work for other windows, but do you skip over the unresponsive window or hang on it?

Floating windows is an interesting idea, but even floating windows are tracked by the application (so that they can become not floating), so you would still have the focus problem. You could just stop keeping track of the window at all. Is there some indication of having done that that makes sense, though? It would be kind of surprising to me if that happened.

[stylerw]

I would advocate stopping tracking the window. You're right that it's a bit odd, but Amethyst loses windows regularly (particularly in some apps), and I'd much rather have "lost" a window from tracking than to have Amethyst break completely in these cases. It's not perfect, and there's perhaps a better solution, but this seems like a much better approach to a very frustrating bug in the mean time. You might also go timer-based. If an app is unresponsive for more than N seconds (5?10?), THEN drop it. This should allow small intense computes to not have much effect, but prevent the slowdown from hurting much in big ones.

This combined with a "Re-capture all windows" shortcut (#371) means that once the misbehaving app gets its life back on track, you can bring it back into the fold easily.

[bradleeedmondson]

I think I'm experiencing a similar problem, with Amethyst sometimes being very slow to respond to either hotkeys or a click on the menu icon. The weird thing is I have apps that use a lot of RAM but usually not a lot of CPU. I mainly only have Chrome (many windows/tabs though), Todoist, Word, and (sometimes) Outlook open, and this still seems to happen every few days. Sometimes the response time is improved or fixed by killing Amethyst, but sometimes it isn't and I have to log out or restart my computer before Amethyst performance returns to normal.

This happens less often if I keep Outlook closed, but it still does happen without Outlook. Am happy to provide stats or logs if you tell me how.

[bupadon]

👍

For me, emacs behaves this way sometimes. It stalls, not responding to window focus events b/c of Amethyst. https://emacsformacosx.com/

[npyl]

I would like this, too! Also a general speed up to the algorithm would be good. For example chunkwm is much faster. I don't know if amethyst could leverage some code from it.

[wildwestrom]

Just want to confirm this is a problem. When Spacemacs initially loads, it doesn't respond to anything. As a result, window management is held up for all windows and screens.