Closed nmraz closed 3 years ago
Many thanks for your detailed report. I'll share with the team who're looking into Windows UX improvements as I mentioned over on #38.
Thanks for forwarding this to the team. I look forward to Task View feeling snappy once more!
I can confirm this exact same problem as well, but I had no idea about the Alt + F4 trick, thank you for sharing that! That's going to be much more convenient than restarting Explorer.
It's pretty easy to crash/restart Windows Explorer by opening task view several times :P. Task View gets especially buggy with Edge, as result of their integration with Explorer starting with v20H2.
Hey all, I'll be closing out this issue as its out of scope for the repo. The performance of UI and other non developer related tech and tooling is best reported via feedback hub. For this issue specifically, file under Desktop Environment -> Task view. We know that the team has been working on improvements in this space for awhile but right now there's no ETA on when they'll be available for Insiders or GA.
Holy f yes I have this exact issue and after I kill my explorer and start a new process it's like instantaneous. Before it was slow as fk molasses, I can get up and sit back down on my chair like 3 times before it'd open. This has been happening forever. Win10 Pro, AMD 1800x (OC), 16GB RAM (OC), OS on m.2 nvme SSD, nice PSU, GTX 1080, 1440p 144Hz.
Tangentially related to #38 - feel free to close this issue in favor of that one if it is a better place to track this.
Environment
Description
Since the introduction of Timeline in 1803, I've noticed that there is a perceptible delay between invoking Task View (whether via keyboard shortcut, trackpad gesture or taskbar button) and the actual start of the animation. At first, the delay is just a split second, but it slowly grows longer as time wears on. I've seen this delay reach about 2 seconds, at which point it is practically unbearable. Restarting explorer fully mitigates the lag (albeit only temporarily).
Online reports seem to indicate that this may be related to display resolution/scaling, so I've included that information as well.
Feedback Hub reports pertaining to the problem:
Steps to reproduce
Use Task View heavily for a prolonged period of time. It looks like the issue only affects certain configurations of certain devices, seemingly at random - I'm experiencing it on a Surface Laptop 2 i7/8GB. Having more than one virtual desktop open appears to make this more prominent as well.
When Task View is already slow, restarting explorer fixes it completely, at least for a short while. It is also sufficient to force Task View's overlaid window to be recreated, e.g. by pressing Alt + F4 when Task View is open (my preferred workaround for the issue). Sometimes pressing Win + Tab multiple times rapidly fixes the issue, after some impressively weird visual glitches.
Expected behavior
Task View should launch instantly when invoked, as it did in the pre-Timeline days.
Actual behavior
I have to wait around 500ms, occasionally upward of 1.5s, for Task View to launch. Sometimes the issue spontaneously resolves itself, but only on every other launch - i.e. Task View alternates between opening immediately and lagging first; when it does respond immediately, it subsequently does not animate shut (windows just snap back into place).
Out of curiosity, I tried peeking into the ETL trace captured by Feedback Hub. In it I found a 1.3s message pump delay almost exactly covered by the
ShowXamlTaskView
event, accompanied by a flurry of CPU usage. After drilling down into the call stack, it looked like a XAML layout call (particularlyWindowsInternal::ComposableShell::Experiences::Switcher::SwitchItemList::MeasureOverride
) was keeping a core pegged for a substantial portion of the delay (902ms of sampled time). I couldn't find anything to explain why the call took so long, but hopefully that tidbit helps anyway :)