AltTab's window sometimes "hangs" for 0.5 to 1.5 sec after choosing a window or cancelling

[mfn]

Version: 6.0.0 Describe the bug I did not notice this with the version before 6 I was using and I just upgraded.

I would say 1 out of 5 times, when I choose (keyboard or mouse) or not choose to select a window (ESC), the over of the thumbs hangs around a bit longer before it disappears (i.e. it's not instant).

Hard to properly reproduce, it just happens sometimes.

• Maybe it's after some time not bringing up AltTab and then quickly choosing a window. That is what just happened while I wrote the issue and quickly wanted to switch somewhere else.
• Yep, same happened again. I finished above sentence and then I could immediately reproduce it again

I use "RecordIT" and tried to capture it, but it doesn't properly reflect the behaviour due to low FPS :/

---

[frypf]

Been running for about 1 hour and so far not noticed any delays on showing the prefs window, which was happening quite frequently before. If I quickly press & release to switch, or hold the shortcut to bring up the list then I've still noticed the delay intermittently, but seems much less frequent now. Attempting to retrace my steps, it seems this happened when the previous switch triggered a space change, and then I call AltTab again shortly (within ~2s) after. If I hold the shortcut to look at the list then I just notice the delay in showing it, if I release before the switcher is shown then it manifests as the glitch from gifs 2/3 above.

[lwouis]

I found another lead! A while ago, I implemented #127, and as part of that effort, I added a timer which checks every 5s if the system permissions (i.e. Accessibility and on Catalina, Screen Recording) are properly checked. It's unfortunate we have to use a timer, but there are no official API to listen for the Screen Recording changes, so there is no choice.

Turns out that at that time I put the timer on the main thread. This means that if for whatever reason, checking the permissions takes some time, it delays updating the UI. This timer is every 5s, so depending on system load and user action timing, it would explain these very random freezes of the UI we have been seeing.

I'll put the timer on a background thread. I think/hope that will finally mark the end of this performance journey!

[lwouis]

For archive purpose: I also investigated (again):

• App Nap
• Sudden Termination
• Automatic Termination

These features were not causing an issue there, but it's good to have that conclusion written here.

[mfn]

The build I started to use ( https://github.com/lwouis/alt-tab-macos/issues/563#issuecomment-688478090 ) does exhibit the latency before the AltTab windows appear.

Shall I upgrade to the latest official release now?

[mfn]

Delay is still happens at times on 6.3.0

[frypf]

Glad to hear you're narrowing it down. Managed to do some further narrowing myself for the issue in gif 1 after I'd noticed it happen a few more times since yesterday. I've only noticed this happen in fullscreen Chrome, and it seems to be related to significant changes in interactive screen content underneath where the prefs window is due to appear. (Eg. clicking web buttons, editing text). Again, this is not wholly deterministic - it doesn't happen every time, but is much more likely. I've attempted to catch a gif highlighting the kind of content change that triggers it:

It reminds me a lot of the issues you mention around 4:50 in this video. In fact, at 5:03 when you select some text in the GitHub comment, it actually generates a bunch of accessibility events, perfectly illustrating your own point! Hope this is of use.

[frypf]

Delay is still happens at times on 6.3.0

Yes but for me at least, it's orders of magnitude less than with 6.2.0, and seems to be related to either WindowServer updates after changing space, or possibly the circumstances described in my most recent comment.

[frypf]

Bringing in @MrBaseMax's comment from #587:

2. And this menu behaves like the option "do nothing" turned on (stays and waits for a click). Which is not. (Also "sometimes").

I can consistently reproduce this one in these circumstances:

• Invoke AltTab shortcut causing a switch to an app in another space.
• Invoke the shortcut again during the space transition, releasing it before the transition completes and before the "Apparition delay" time is complete.

[MrBaseMax]

Bringing in @MrBaseMax's comment from #587:

2. And this menu behaves like the option "do nothing" turned on (stays and waits for a click). Which is not. (Also "sometimes").

I can consistently reproduce this one in these circumstances:

• Invoke AltTab shortcut causing a switch to an app in another space.
• Invoke the shortcut again during the space transition, releasing it before the transition completes and before the "Apparition delay" time is complete.

Yes, usually caused by the second shortcut pressed in a row. But i use mostly just a single space. So, do not see the dependency

[frypf]

But i use mostly just a single space.

And no fullscreen apps?

[lwouis]

@frypf I was able to reproduce this issue. I will open another ticket for this. It's not related to freezes or visual glitches. It's a bug with shortcuts

[frypf]

Lets continue the shortcut discussion in #588 that @lwouis just opened. Apologies for confusing that issue with this one.

[lwouis]

How about the freezes and visual glitches in 6.4.0?

[MrBaseMax]

How about the freezes and visual glitches in 6.4.0?

Still there :(

[lwouis]

What exactly do you observe? We need detailed a description, and steps to reproduce and video would help a lot of course. Only through detailed feedback will we have a chance of assessing the current situation, and come up with a solution.

[frypf]

How about the freezes and visual glitches in 6.4.0?

Still there for me but very intermittent and I'm increasingly sure only:

• shortly after a space change (switcher window delayed)
• shortly after computer wakes from sleep (switcher window delayed)
• after interacting with web content, eg typing or re-rendering web content after a button click (prefs / about / update window delayed)^[1]

[1] Now confirmed this separately in Brave, Chrome, Safari, and now VSCode as well. Can confirm fullscreen status is not pertinent.

[MrBaseMax]

What exactly do you observe? We need detailed a description, and steps to reproduce and video would help a lot of course. Only through detailed feedback will we have a chance of assessing the current situation, and come up with a solution.

I see delays of a second or more, even when UI have to gather thumbs only for current app windows. More often it happens when changing combination (press 10 times combination "2" – last one choose thumb with a mouse – and then combination "1")

And sometimes in the similar circumstances something big winks, i think it's the ghost of previous UIs

More rare case is while doing the same combination again and again suddenly much longer delay takes place. (May be caused by the common interface lag with integrated graphics at new macbook pro 16)

[frypf]

Ok I've noticed the delay showing the switcher once now where a space transition definitely wasn't involved. However, my jerry-rigged menubar CPU temp monitor was indicating a spike in activity at the time. @lwouis do you know if it's possible (or helpful) to run Instruments on WindowServer? I've found the executable in the private Skylight framework but obviously as it's single-instance, it just stops profiling instantly. I just thought I'd try to see if my AltTab delays were showing any corresponding high CPU activity in WindowServer to at least rule that out.

Ok, just realised I can run it on the system as a whole and pick the results I need out afterwards. Will keep you posted.

[lwouis]

@frypf Use Instruments with System Trace instead of the usual Time Profiler. It will not only sample AltTab, but also sample the system process, including WindowServer. You can see the example I posted above. There are then many indicators and much data that you can look at. It's all fairly low-level though, so may be hard to read if you're not proficient in how macOS works.

[frypf]

Will move onto System Trace now. I just tried it with the general Activity Monitor profiler and managed to trigger another same-space delay, and checking back in Instruments it corresponded with WindowServer at 57.8% CPU and AltTab at 5.3%.

If I'm honest it's mostly been your videos that have given me any clue how to look at this stuff anyway, and I've found them very helpful while trying to develop my own little CLI thing. I can read a thousand manuals, but nothing teaches me better than watching someone doing something and trying it for myself.

[mfn]

FWIF, also seeing delays in bringing up the AltTab window with 6.4.0

[frypf]

so may be hard to read if you're not proficient in how macOS works.

Wow, you were not kidding 😂

[lwouis]

Here is a build in which I have disabled the sync loading of the first 3 thumbnails. All thumbnails are loaded async, after initial display of the UI in this build.

Please try it out and let me know if it improves things somehow

[gquittet]

On 6.4.0 (even on the custom build above), I've got the delay of 1s before Alt-Tab is showing.

I'm on a MacBook Pro 15 2019.

I downgraded to 5.3.0 and everything is working great.

Maybe you have to downgrade waiting a fix.

[frypf]

Still same issues as described before. After running System Trace a few times my delays in showing the switcher correspond to a spike in WindowServer activity, a big spike in kernel activity, and a small spike in AltTab at the point the window is shown. I'm definitely not able to make much sense of it beyond that, and after saving I realised it was 1.6gb (I know there's a lot of info in there, but this seems huge). Looking further back through the traces I realised the same spikes were often present on the occasions where the switcher showed without any delay.

Attempting to quantify it a bit better, with 6.2.0 I would say that for me the delay manifested ~ 1 in 20 interactions with AltTab. After the async App Badge code you pushed that reduced the frequency to ⅓-½ of that, if not lower. Subsequent builds haven't really made a dent in it any further.

Please let me know if you need me to pull anything from the .trace docs - I'd upload them but they're massive and possibly not even of use. (I removed the screenshots as I realised I was misinterpreting the timing.)

[lwouis]

@frypf thanks for sharing this analysis. It's hard to draw conclusions though, as you've seen for yourself.

@gquittet you're saying that on 5.3.0 the freezes are gone? From your perspective, 6.0.0 introduced these issues? 6.0.0 introduced loading the thumbnails after showing the UI. So clearly if you have 30 windows open, it's possible that even with the freeze before the UI shows, it would still be faster than on 5.3.0 where there is a natural wait to show the UI as the thumbnails are being updated before showing anything. Doesn't 5.3.0 feel slow in that regard?

[lwouis]

On my machine, I see 3 problems happening:

• After not using AltTab in a few minutes, when I trigger it next, there is a delay before it shows its UI. This one feels to me like it could be due to:

  • The OS putting low priority on the app. You can set QoS for threads and dispatch queues, but how does it work for the main thread? Is there a priority penalty being a background app?
  • The OS putting its RAM in a special state?
  • ~The OS putting the app in App Nap?~ (there is now code to prevent that in AltTab)
  • Some cache being expired, like the NSView layer being cleared, and AltTab has to reconstruct it?

• Randomly, when the UI is in the process of appearing or disappearing, it shows this visual glitch of showing the outline of the window, but the contents are not correct. It's kind of transparent, showing the contents underneath, while still showing the window's box/outline and shadows.

• When AltTab shows its UI, and the window has changed size, it shows the previous window for a few frames, then shows the correct window. A way to trigger this is to switch between the 2 default shortcuts, or set the preference to show different types of windows, then trigger AltTab again so there is less/more windows to be shown.

These 3 issues seem independent to me, but maybe there are not. Regarding actionability, I think issue 3 is reproducible semi-consistently, and I have ideas on what's at play. For issue 1 and 2, I'm at a complete loss, without any lead on what is happening.

Also noteworthy is that I captured all 3 issues in Instruments in the past, and I have never seen activity within AltTab matching the duration of the issues. AltTab is never doing work on the main thread that would be blocking rendering.

[mfn]

• After not using AltTab in a few minutes, when I trigger it next, there is a delay before it shows its UI.

FTR this is the issue I'm practically encountering all the time. In fact, very often in recent times. Also happens with the build from https://github.com/lwouis/alt-tab-macos/issues/563#issuecomment-689055871

[mfn]

I again went back to v5.3.0 and yes, it feels immediately different if one pays attention:

• I do not have this "exorbitant high" (in comparison!) delays bringing up AltTab
• when v6 brings up the windows without the delay, it is definitely much faster than v5

But the occasional long delay, which basically makes me have to wait before I can switch windows, makes me rather use v5.3.0 and live with that it generally comes up slightly slower but I don't experience these longer delays at all.

[gquittet]

We should use git bisect to find the exact part of the code that has a huge impact on the performance between 5.3.0 and 6.4.0.

I can do it but I have no idea on how to compile alt tab on my Mac 🤔

[lwouis]

We should use git bisect to find the exact part of the code that has a huge impact on the performance between 5.3.0 and 6.4.0.

It may be useful to download 6.0.0 and see if it displays the issues. That would reduce the scope of the bisection, if it turns out it was already happening in 6.0.0

I have no idea on how to compile alt tab on my Mac 🤔

It's extremely easy. I documented the steps here.

[mrc247-DE]

after updating from 6.2.0 to 6.4.0 I notice a big delay when, in my case, pressing command + tab.

It doesn't always happen, but it happens frequently and causes irritation.

in version 6.2.0 everything was still ok.

[mfn]

I think we're narrowing it down!

I tested with 6.0.0 a while and didn't see this hangs.

[lwouis]

First, let's try to be precise, as there are multiple issues at play here.

Regarding issue 1 in the link above, I just tested all versions myself, and narrowed the regression. It happened between 6.2.0 and 6.3.0. I'll try to find which exact code change brings the issue now

Update: this is the commit that introduces issue 1: fix: load app badges asynchronously to avoid system lag (closes #563) (29eff03e)

[zzamboni]

Glad to see the long discussion here. I've been thinking over the last few days that I was slowly going insane, since I've seen some of the behaviors described here, on and off, for a few days. I am pretty sure they started at or after v6.0.0.

There are two particular behaviors I have observed:

• Slight delay when pressing the shortcut before the thumbnails come up. I thought it was computing the thumbnails. This seems to happen more often when I have my external 4K monitor connected, but it also happens without it. Seems more often after a while without having triggered AltTab.
• A few times, when I have my external monitor connected, I have seen AltTab completely fail to appear. It still switches to a new window, but the thumbnails never appear on screen. This has only happened with the external monitor, and in those cases it seems necessary to restart AltTab to bring it back.

I'm on 6.4.0 now, and the first issue is still happening. I have not seen the second one in a while, but I will keep an eye for it.

@lwouis what would be useful information to collect when these issues happen, to help you diagnose them?

[lwouis]

Hey everyone, so I think I identified the issues with the 29eff03. I made some changes, and I think that issue 1 is gone. Issue 2 is still there though. And issue 3, I think is gone but less sure.

Could you please try this build out, and share here your results regarding the 3 issues?

[ghost]

Hey everyone, so I think I identified the issues with the 29eff03. I made some changes, and I think that issue 1 is gone. Issue 2 is still there though. And issue 3, I think is gone but less sure.

Could you please try this build out, and share here your results regarding the 3 issues?

Just tried this build for an hour. I will speak to the issue that I've observed. Some observations / possible clues:

• Don't think you've amended 'Shortcut 2' like you have 'Shortcut 1'. Higher rate of the slowness issue.

• The bug rate seems to be less if you are on dGPU (and not iGPU). My hardware: 16-inch MBP.

• Possible clue: I think some apps are exacerbating / triggering the issue. E.g. Google Chrome. I spent a good 20 minutes alt-tabbing between TextEdit and Firefox with zero slowness. This might have to do with video graphics somehow.

My 2c: until this particular bug can be resolved fully, I'd vote for making it be sightly slower vs. instant lightning speed, if it means less 'super slow' instances.

[lwouis]

@mindfulsource I can't believe you are still getting issue 1. For me, running 6.4.0 locally, i just wait, and can get the freeze when I trigger AltTab after a few minutes. Then i run the build I shared, and this is gone every single time. I tested for a few hours and the issue is just no longer happening for me locally.

Can you precisely describe which issue you are referring to? You may not be talking about issue 1.

[zzamboni]

@lwouis With the latest build, the delay on AltTab appearing seems to be gone. I have not tested in my dual-monitor setup, I will report later when I have a chance to test.

[nfekete]

I'm also on 6.0.0, which I reverted to using after facing the issue of the long delays in a later version (6.3.0 I think). For me, in 6.0.0 long delays rarely happen (if at all), while on 6.3.0 it happened quite often. I'll try the new 6.5.0 release and report back.

[mckennajones]

I noticed AltTab was taking a while to appear, clicked "Check for updates..." and there was the bug fix for this issue. Cheers @lwouis and everyone else who contributes to this awesome app!

[nfekete]

6.5.0 feels nice and snappy again. This is going to be my baseline version from now on, after 6.0.0.

[zzamboni]

Same for me - I've been using the earlier build and now 6.5.0 for a while, also on my dual-monitor setup, and it seems fine. Thanks @lwouis for all your work on diagnosing and fixing this!

[ghost]

I've updated to v6.5.0 but I'm sorry but I'm still getting it. Not as often (which is great), but yes periodically. (I'm on forced dGPU right now. If I switched to auto / iGPU most of the time, I think the issue would come back more.)

I am on a MacBook Pro (16-inch, 2019). Specs:

2.6 GHz 6-Core Intel Core i7 64 GB 2667 MHz DDR4 AMD Radeon Pro 5500M 8 GB Intel UHD Graphics 630 1536 MB

It may be related to some graphics issues this model is having. MacRumors forums have us talking about them.

[mfn]

Hey everyone, so I think I identified the issues with the 29eff03. I made some changes, and I think that issue 1 is gone. Issue 2 is still there though. And issue 3, I think is gone but less sure.

Could you please try this build out, and share here your results regarding the 3 issues?

Can confirm since I run this build (1h?) I haven't seen 1), the initial hang before the window appears, once. And usually it would _not take longer than a few minutes.

🎉

[ghost]

I keep on getting it. I think I want to go back to an earlier version like 5.0, see if it goes away. Would that be helpful @lwouis?

[mfn]

Can confirm since I run this build (1h?) I haven't seen 1), the initial hang before the window appears, once. And usually it would _not take longer than a few minutes.

In the meantime I could see the hangs but they seem much less frequent. First time I saw it since I installed the new build was a few minutes ago when switching between "in-app" windows but since then also saw it when switching between all apps windows.

---

Like, I was writing above sentence and writing and writing and though I would test it, press cmd-tab and did experience the hang (without switching). Then tested it again, super fast. Then tried cmd-~ for in-app switching and immediately also had the hang.

After writing above sentence and not switching away anyhere:

• cmd-tab => almost instant all windwos, esc close
• cmd-~ => hang

[lwouis]

Yes, any kind of "it never hanged on that version" information is of course useful. I found the regression above, clearly during my local tests. Now if you guys still experience issue, the question is: what's the version where it didn't exist for you? For me, the regression is clearly between 6.2.0 and 6.3.0 but apparently it's not the same for all of you

[ghost]

I just tried v6.0.0. It still has the delay issue. Very early, very quickly, 3 times in just a couple minutes.

What's the earliest version that anyone has reported the issue (of delay in entire AltTab showing)? I could try going one revision before that and reporting results.

[mfn]

For me, the regression is clearly between 6.2.0 and 6.3.0 but apparently it's not the same for all of you

I'll chase down this one from my side. It may take some time because as experience has shown, running 1h might not be enough to attest if the problem still exists or not