5

I recently switched from Ubuntu Desktop 18.04 to Ubuntu Desktop 20.04.

I noticed that the Alt+tab performance is significantly slower in 20.04 than in 18.04. I did not notice a delay when I Alt+tab to switch between windows in 18.04. But I notice an approximately 1s delay when I use Alt+tab in 20.04. Alt+tab+tab also has a noticeable delay when displaying the windows selection panel.

My question is:

  1. Do other people also face this slow Alt+tab behavior in 20.04? Or is this just because I am using an old laptop? (Intel CPU i5-6200U, 16GB of RAM)
  2. What can I do to speed Alt+tab up?
Improve this question
2
  • I'm seeing this too, on a decent laptop (X1 6th gen). I saw in the writeups that there were some improvements to alt+tab behaviour but I dispute this!
    – Lorna Mitchell
    Jun 2, 2020 at 9:11
  • I have the same CPU but don't see much delay!
    – VidathD
    Jun 5, 2020 at 11:55

4 Answers 4

Reset to default
0

(Answering my own question)

I am using a Dell Latitude 3740 laptop with BIOS version 1.1. After updating the BIOS to version 1.16, Alt+tab performance and Alt+tab+tab performance are now much smoother without any noticeable delay!

Am not sure if the BIOS update is 100% the cause of improvement. Would be surprised if it is.

Improve this answer
0

I had a similar problem, some people were recommending installing nVidia drivers, but my laptop has intel integrated graphics. Actually just rebooting a second time after installing the update helped solve my issue.

Improve this answer
0

Well, I suffer the same issue with Ubuntu since I've been using it exclusively (my one and only OS), for instance, since 14.04.

The problem seems to appear mostly after having a significant period of time without rebooting, and it happens to me only when I've been using several apps and RAM is been compromised (less than 3 GB available), I'm not sure if it's something caused by RAM, though.

Also, I've been monitoring resource consuming and the CPU is mostly idle (>90% idle), my config is an i7 7700HQ with 16 GB of RAM and an SSD NVMe M.2 240 GB + HDD 1TB (with swapping active there).

It gets solved when I restart the system, but I think it has to be a bug or something, because having lots of RAM space available, and CPU quite a bit idle, I don't see any reason for this to happen.

Improve this answer
0
0

One known work-around is simply to restart the gnome-shell from a terminal:

   killall -SIGQUIT gnome-shell

Another possible solution (that I'll try out the next time Ubuntu desktop my is choking) is to use the perhaps slightly more humane command:

    gnome-shell --replace
Improve this answer
3
  • do these reboot gnome shell? Do they work on Wayland? I know that Alt-F2 r doesn't work on Wayland
    – artfulrobot
    Apr 30, 2021 at 13:07
  • So... my commands will effectively give you a fresh gnome-shell instance with all windows retained with size, position, and even workspace (did so here at least). If you're asking about the specifics of what's going on under the hood, then I don't know for sure, but my guess is that the gnome-shell process is killed and something (maybe a wrapper script) respawns a new instance; since X itself didn't get killed, all client (meaning windows with apps) survive. It would be interesting to know exactly what's happening, and how the windows properties are retained ... and if I'm correct.
    – Stephan Henningsen
    May 3, 2021 at 20:13
  • I don't use Wayland, so I can't say. But it sound like you are, so I recommend you just TIAS. I don't have r it either here on Ubuntu 20.04, maybe that's why it doesn't work for you. Maybe that command was shipped with some older versions of Gnome, or maybe Unity. I think you should forget about it and run gnome-shell --replace instead.
    – Stephan Henningsen
    May 3, 2021 at 20:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .