search

lwouis / alt-tab-macos

Windows alt-tab on macOS
https://alt-tab-macos.netlify.app
GNU General Public License v3.0
10.86k stars 326 forks source link

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

Closed mfn closed 2 years ago

mfn commented 4 years ago

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.

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

jbETlzsvkC

mfn commented 4 years ago

I see everyone using loom or so, but it needs registering AFAICS which I didn't want to use. I use the free version of RecordIT (due to low FPS) but that's usually enough for me.

If anyone can recommend another screen recording app which doesn't need registering and produces better results, I'm open to suggestions!

lwouis commented 4 years ago

Hey again @mfn! Thanks for sharing this issue!

I noticed this during development for 2 days. I thought I was going crazy because it's so inconsistent like why is it happening? I tried to capture it in Instruments to profile it, but it only happened once there, and there was basically no activity in AltTab, so I thought "ok it's the WindowServer being slow to respond for some reason, nothing I can do about that".

It's either some multi-threading issue, or OS interaction like stressing out the WindowServer in burst or something. I'm sad to hear it's happening on other people's computer too. I thought it was only on my system. I'll try to work at it, somehow.

For the video software. I used OBS in the past. It records in top quality, but then you have the issue of where to host the content to share it. Loom is incredibly plug-and-play. Yes you need an account, but then it's a one-click to record and share with others. They pay the video hosting, so I feel it's fair to sign up. They are trying to run a business, and their product is good. Any free software is going to put the burden of hosting the video on you.

lwouis commented 4 years ago

Questions to help me investigate:

lwouis commented 4 years ago

I got a ~1s freeze during profiling. It's always during shortcut release, when the AltTab main window should hide, that it freezes before hiding. I think the freeze happened during the first 2s on the screenshots, on the top left you see these orange spikes in activity:

image image

When I look at these, especially the first one, I see the main thread is mostly idling. Basically it's running its code very efficiently, then doing nothing. If the freeze is not due to some code in the main thread not finishing fast, then the only explanation I have is that it's the window server being slow giving the thumbnails or the AX info (e.g. titles, roles, etc).

What puzzles me, is why this is happening on the latest version. If anything, the code is more efficient than ever. Anybody has an idea?

mfn commented 4 years ago

Do you remember these freezes happening on previous releases, or is it a new thing?

No, it started today when I installed 6.x, as I wrote:

I did not notice this with the version before 6 I was using and I just upgraded.

Do you have BetterTouchTool running?

No, never heard of.

I might even downgrade, it really happens very often; now I would say the number is 3 out of 5 for me.

lwouis commented 4 years ago

I've been trying to reproduce for 2 days now, but I can't get it to happen anymore. I was running some local changes that are now release as part of v6.1.0.

@mfn could you please tell me if the issue still happens to you with v6.1.0? I'm really trying hard like plugin my 4K TV and putting 8 4k youtube video to stress the WindowServer, and other things, but I can't reproduce the issue for the life of me. Maybe of the changes in 6.1.0 got rid of the issue. I hope so at least.

mfn commented 4 years ago

Roger, I just updated to v6.1.0 and will continue observing the situation!

frypf commented 4 years ago

I updated earlier today and have unfortunately noticed this a few times since. I hadn't actually noticed it in previous versions, although I've been having another issue and it's only been while fiddling with the AltTab settings that it's even come up.

I've also found it near impossible to reproduce. For me it seems to be related to changing the fade out animation and apparition delay, and I've only had it happen while the prefs window is open. Even then it's not consistent, happening maybe three times out of probably hundreds of app switches over the last few hours.

lwouis commented 4 years ago

I've only had it happen while the prefs window is open

I'm not sure 100% but i think it is also the case for me that whenever i witnessed this issue, the prefs window was open. Same for you @mfn?

mfn commented 4 years ago

For me it seems to be related to changing the fade out animation and apparition delay, and I've only had it happen while the prefs window is open

I can't confirm this, I don't remember the last time I was in the settings [1] and they're never open.

But besides that, since 6.1.0 I have not experiences the delay yet.

[1] Actually I do, when I learned that we can switch in-app, I enabled it a few weeks ago ;)

mfn commented 4 years ago

The delay is back AKA today, I just started working ~10mins ago, I already noticed in twice. can't say much about yesterday, was too late & tired.

lwouis commented 4 years ago

Anybody good with Instruments? I'm kind of stuck here on how to investigate this issue further.

mfn commented 4 years ago

It happened a few seconds ago and what I was doing right before: I switched a branch in PhpStorm and re-indexed was triggered (lots of files changed), and during that time I switched.

CPU spike/lag/throttle/… ? However I could not reproduce it that way. Maybe because the second time the disk cache softens this… 🤷‍♀️

mfn commented 4 years ago

No, that's not it. At least: not alone.

I had it a few times happen in the last 2 hours without being aware of triggering an CPU intensive operation before that. E.g. switching already before loaded browser windows.

lwouis commented 4 years ago

My guess is that it's either:

mfn commented 4 years ago

I mentioned it elsewhere but not here yet, so to have it one place my specs:

Additionally I use two external FullHD monitors.

From what I remember, the only other software constantly "active" regarding the display is f.lux (disabled Apples own version of that) but I don't remember it ever interfering with anything.

frypf commented 4 years ago

Not sure I can help much further with this one unfortunately. My machine is considerably less powerful (mac mini / i3 processor / 16gb ram), so in theory the proposed resource bottleneck might be a more frequent problem for me, but then I'm only running a single screen at a much lower res and not generally doing anything intensive. Other times I've experienced general lag on my system it's usually been down to WindowServer.

I've only noticed the delay once more since my previous post. The prefs window was definitely open again at the time, but I'd been changing a different setting so I don't think it's related to changing the value of any specific setting (for me at least). I will of course keep monitoring and report back if I notice any other discernible pattern as to it's cause.

lwouis commented 4 years ago

@frypf I also suspected it was an interaction with the Preferences window, but @mfn says it's never open on his machine yet he experiences the issue.

From my perspective:

frypf commented 4 years ago

@lwouis I was just adding to my previous comment when your reply came through. I've managed to narrow it down slightly more, but no idea how helpful this may be:

I've been able to reproduce it a few more times in the last hour. While the following steps won't reproduce the problem every time (more like 1 in 20), I've not noticed it at all under any other circumstances:

I also noticed that a few times the prefs window takes a similar amount of time to appear when I called it via the menu bar, rather than appearing near-instantly as it usually does - although this seems to have no bearing on whether I then experience the same delay when switching back to AltTab from another app.

At this point I'm increasingly unsure that my own issue isn't just down to resources and WindowServer, although it's weird that it only seems to happen after I open the prefs anew and adjust a slider, and even then it's only occasional. Subsequent interactions with the sliders don't seem to reproduce it, only when I change one after reopening the prefs. Being so specific and intermittent, it's certainly not affecting my workflow to any extent as it seems to for @mfn. Perplexing, and quite possibly unrelated / unhelpful with the original problem, so apologies if my input has been a red herring!

lwouis commented 4 years ago

@frypf doing these exact steps seems to make it more likely to happen indeed. Thank you a lot for your support in attempting to find reproduction steps. I really appreciate it!

frypf commented 4 years ago

No worries, glad it's not just an idiosyncrasy of my own mac!

mfn commented 4 years ago

I'm not sure if I did not pay proper attention or not so far, but what I noticed definitely since yesterday day is that it takes longer than expected to "bring up" the list of windows.

I would say 1 out of 10 times I press cmd-tab and it takes up to 0.25-0.5s, hard to pinpoint) to bring up the window.

I wonder if I should go back to 5.x and positively confirm it does not happen there? 🤔 As I initially wrote, I didn't remember having this before

lwouis commented 4 years ago

@mfn yes of course, any data point is helpful in trying to find the root cause so we can fix it. Comparing with v5, sharing screen capture of the symptoms, etc, it's all very useful, as these problems seem to vary across machines

mfn commented 4 years ago

Roger, using 5.3.0 now

lwouis commented 4 years ago

~Could you please try out this build I made for another ticket? It's performing great on my system.~

Nevermind, I had the issue happen

mfn commented 4 years ago

image

I don't recall having this hangs since I'm on v5. I'll stay on that version and continue throughout today.

lwouis commented 4 years ago

~New build. I changed some displays related things, while working on #566. Maybe it helps? I haven't seen the lag yet~

Nevermind, still happening

lwouis commented 4 years ago

I caught the issue on video, in a profiling session. I verbally go through my analysis, and why i'm stuck with this issue.

If you can, please check out the video and let me know if you have an idea what could be going on.

Here is the .trace document if you want to study it in Instruments for yourself

lwouis commented 4 years ago

Oh wow, I reviewed the footage, and if actually looks like the whole system UI is freezing up for a second. I first noticed that the Instruments moving graph was freezing, but then I thought that it may be freezing because AltTab itself is freezing or something. They are interacting somehow so it's not enough to conclude.

But then I checked the iStats graphs on the top right corner of the screen. Pay attention to the SSD and NET graphs on the right. Notice how one refreshes, then the other, then the first, etc. Count the tic-toc-tic-toc-... in your head. When AltTab freezes, this part of the UI also freezes.

I really looks like macOS is the culprit here! What do you think?

lwouis commented 4 years ago

I'm not able to reproduce the lag (for now at least) using this build. Could you please try it out and let me know?

Btw I'm sorry to ask for help on so many builds, but it's kind of the only way to do QA in the real world scenarios we have here. It's beta-testing basically. Your support is really appreciated 👍

frypf commented 4 years ago

It's beta-testing basically. Your support is really appreciated 👍

Absolutely no problem, you're putting in the hard work pushing out a bunch of simultaneous solutions to issues and feature enhancements, so it's kind of the least we can do. At least you're up front about it, which is more than I can say for several bits of paid software I've had in the past. I'm starting to confuse myself a bit referring to all the various builds between threads though so we need a naming convention for these tests. Maybe just use the github file number for now as a quick/ dirty solution, or reference the latest commit you've incorporated when you write the link?

I've noticed the lag a couple of times with the version above, but still only with the prefs window open, so not sure if it's a slightly different issue to @mfn. I've written my other findings in our discussion #566, so I'll avoid polluting this thread any further unless I start noticing this without the prefs being open.

lwouis commented 4 years ago

Maybe just use the github file number for now as a quick/ dirty solution, or reference the latest commit you've incorporated when you write the link?

You can also simply link to my link. For example you would say "I tested and had results X with this build". Notice how the link point to my comment above, itself containing the build. That way it's easy to know because you click the link, and see the build, in its historical context.

SoPat712 commented 4 years ago

Shouldn't this be open if the bug still exists? You closed my duplicate, but which one is the origin thread now?

lwouis commented 4 years ago

Oh, it was closed automatically because of a reference in a commit, which I forgot to remove. My bad, reopening.

If you want to help fix the issue, you can review the latest investigation from this comment, or you can try to help us understand the root cause by finding scenarios that deterministically reproduce the problem, or guess at what could be at play here.

SoPat712 commented 4 years ago

Are we sure it's not display stuttering or something else unfixable? Or heavy processor load as a result of alt-tab causing a drop in frames? I'll take a look at the code as well, I think swift is close enough to Java for me to be able to understand it. Also, have we yet pinpointed a version upon which this began, because knowing which commit to look at would really help.

lwouis commented 4 years ago

These questions have been answered in the discussion above. Please refer to the link I just shared. It contains a video in which I showcase the issue, and go over my best guess as to what is happening. Yes it could be a system limitation. It could also be an issue with AltTab. Hard to say. See the video. You can also use the .trace and import it in Instruments, to try to understand the issue.

I think this issue was introduced with v6 (previous version was 5.3.0). The main change in v6 is that thumbnails are retrieved asynchronously compared to synchronously previously. This is the main commit. This change may have introduced a bug, or may have unveiled limitations of the OS.

SoPat712 commented 4 years ago

I'm not able to develop swift, but is there a way you can do something like thread.sleep for a couple of milliseconds to let the OS catch up? Otherwise, is there a way we can cache unchanging thumbnails in the background so that alt-tab doesn't have to work so hard? Sorry for my bothersome questions, I'm not exactly a person up to date with development of Mac applications or even understanding MacOS as a whole.

lwouis commented 4 years ago

like thread.sleep for a couple of milliseconds to let the OS catch up

What would be the point of that? How long would we wait? How would we know that waiting is need? I don't see the point of this. We could go back to doing it synchronously if we want to wait. Also we are not sure at all the OS needs to catch up. It needs to be proved.

is there a way we can cache unchanging thumbnails in the background so that alt-tab doesn't have to work so hard

This is exactly what v6 introduced: the thumbnails are shown immediately within a less than 50ms from the shortcut trigger. Then AltTab asynchronously update them 1 by 1. In the past, if you had 100 open windows, AltTab would synchronously get 100 screenshots from the OS (in parallel tasks, with a fork/join approach, so it was not too slow). With v6, AltTab will get the first 3 (most looked at) window screenshots synchrously, then show the UI with the other 97 thumbnails in their previous/cached version. Then start updating them 1 by 1. If the user closes the UI during this fetching, it stops, so I don't know if the fetching is even what's causing the freeze. I don't know what's causing the freeze at all.

Have you watched the video I recommended above?

SoPat712 commented 4 years ago

I've just watched the video above, and I think I understand the issue a lot better now. Regarding sleep, thread().sleep in java works to stutter certain processes that take place on processor cores, setting them in an artificial suspended state,. It gives time for alt-tab or other applications to get its own processing time. This is from Oracle documentation "This is an efficient means of making processor time available to the other threads of an application or other applications that might be running on a computer system". I'm not sure how this works in Swift, and don't know how it would really work, and once again, I'm not a MacOS app developer, so make sure to take my advice with a gallon of salt haha.

mfn commented 4 years ago

Maybe just use the github file number for now as a quick/ dirty solution, or reference the latest commit you've incorporated when you write the link?

I also have the problem that, after a few days, I literally don't remember which version… so far it's manageable but maybe error prone 😅

From https://github.com/lwouis/alt-tab-macos/issues/563#issuecomment-686930623

I'll now use the build from https://github.com/lwouis/alt-tab-macos/issues/563#issuecomment-687093108

lwouis commented 4 years ago

@mfn please use the public release instead. All the builds in this thread were made while I was trying to close the latest releases. The latest and greatest code is now in 6.2.0, and it would be best to use it as the baseline. If we come up with hypothesis I'll make new test builds, but for now let's only discuss the latest public release for the issue, and 5.3.0, 6.0.0 to confirm if indeed the issue started with 6.0.0

mfn commented 4 years ago

Ok, done!

mfn commented 4 years ago

Oh my, I just re-read the title I wrote:

AltTab list of thumbs sometimes hangs for 0.5 to 1.5 sec after choosing a window or cancelling

When in fact in all recent tests (i.e at minimum since last week) what I experienced was rather a delay in showing AltTab windows at all

Aka, this delay I was all the time recently saying I still have it, in fact it was about bringing up AltTab. And not so much after choosing a window and then switch.

I am so so sorry and I start to confuse myself here. AKA the worst possible combination of all when reporting and then not even the same thing.

I will swear I will pay more attention to this.

I was just about to say "I still can reproduce it" when in fact I was really talk about the "startup" delay I experience sometimes when I press CMD-tab to bring up the windows.

I definitely did do experience the original issue but at some point this all got fuzzy and I started to report I experience the original issue when in fact I experiences the one I'm describing now.

I need to go back and collect myself, I really really feel back for this confusion.

Again, apologies and please let me know if you have an idea how to best proceed with this issue.

☹️

frypf commented 4 years ago

I'm not sure if I did not pay proper attention or not so far, but what I noticed definitely since yesterday day is that it takes longer than expected to "bring up" the list of windows.

When in fact in all recent tests (i.e at minimum since last week) what I experienced was rather a delay in showing AltTab windows at all

I was reading through the thread again and was actually going to ask for clarification on this. Both these quotes describe the issue I'm now noticing more myself, which seems to have moved away from the original delay upon releasing the shortcut (as mentioned in both the title and shown in @lwouis's video).

I'm experiencing an infrequent delay in showing either the AltTab switcher or prefs, but have not noticed any more delays when actually switching to another app (as in the titled issue). I had just been attributing this to resources and WindowServer, or possibly my own key-release timing during space transitions after the work @lwouis put in on #566. However I've since noticed it occasionally without any space transition being involved, for example this is how it looks when showing the prefs:

prefsDelayGlitch

When switching apps without a space transition, it doesn't typically manifest with the visual glitch and so is much harder to capture. Managed to capture it by reducing apparition delay to zero and switching to app at position 3 in the list (ie holding modifier and hitting tab 2x in quick succession). This isn't reproducible every time, this was attempt number 22:

switcherSameSpaceDelayGlitch

And if a space transition is involved it looks like this:

switcherDelayGlitch

Just want to check with both @lwouis and @mfn that I'm not further confusing the issue or talking at cross purposes. I'll keep searching for reproduction steps, but it's proving really hard to put a finger on.

lwouis commented 4 years ago

Anyone knows a good macOS developer we could ask for advice? These graphical glitches are beyond me 🙉

I don't know what to do. Everyone seems to be experiencing slightly different, indeterministic symptoms. And these symptoms do not manifest in any tangible way in profiling reports.

andylima commented 4 years ago

Anyone knows a good macOS developer we could ask for advice?

@lwouis http://twitter.com/MacSparky knows a lot of Mac devs — I think he could be of help. 🙂

(I'm also having this issue since using that "disable thumbnails" preview build… Not sure which version I had before — probably one of the v5 ones.)

frypf commented 4 years ago

I think in one of your videos you mentioned that counterintuitively the rendering glitches and delay showing windows may be caused by AltTab's windows attempting to show too early, before they're actually ready. This tallies with the fact that if I turn the "Apparition delay" up (above ~500ms) I don't remember seeing the graphical glitches happen at all for same-space transitions. Interestingly though, even with this set high I still experience occasional similar glitches when opening the prefs (which obviously isn't subject to the Apparition delay setting). When switching apps across spaces the issue also still happens, albeit less frequently (the switcher window sometimes ignores that setting entirely and attempts to show itself, sometimes successfully, sometimes with the glitch).

Your knowledge is levels above mine so I feel like I only ever end up highlighting issues without being able to contribute anything concrete to resolving them - hence my possibly overzealous hunt for reproduction steps.

I've only been a lurker on the Yabai forum, but @koekeishiya always seems a fountain of knowledge, although having read an increasing number of threads both here and there I know you guys already have a connection, and he's never not busy.

lwouis commented 4 years ago

Oh! I was working on #289 and I caught this in the profiler:

image

This is a big catch! In terms of timing, I have been personally suspicious that some of the freezes started happening around the time I introduced the app badges. It's a synchronous request I added kind of quickly. It's very possible, as the picture shows, that this call sometimes hangs a lot, when the Dock or WindowServer is busy.

I will try to make the call async like the thumbnails

lwouis commented 4 years ago

Here is a build with async app badges. Could you please tell me if it improved things?

On my system it's insanely fast, and all kinds of freezes are gone. For instance, I realized that triggering AltTab while windows where in the minimization animation was a good way to get freezes. With the async badges change, I can trigger any such animation, and AltTab is super responsive

mfn commented 4 years ago

I just installed it.

After a few minutes, when I switched windows within PhpStorm, upon CMD-~ it took a few more ms than expected until the list of windows did show up (5 windows in total).