GNOME Shell Performance Improvements in Ubuntu 20.04

GNOME Shell Performance Improvements in Ubuntu 20.04

The release of Ubuntu 20.04 brings GNOME Shell 3.36 and improved performance in some areas. In this article we will describe the improvements that were contributed by Canonical.

As most Ubuntu users tend to stick to LTS releases they mostly will be upgrading from 18.04. If that’s you then you will also notice a larger set of performance improvements introduced in 19.04 and especially in 19.10. So you might like to read what those are first.

New in 20.04

All animations are slightly smoother, and some have lower latency

An animation is just when something moves through both time and space. But even animations that didn’t skip frames (were smooth in time) weren’t looking as smooth as they could be. This occurs when an animation uses an irregular series of positions on screen. Now we sync those positions to the strict interval your screen will emit the photons on, so there’s a slight improvement in visible smoothness.

And since we’re now being very specific about when photons get emitted we can synchronise the screen contents more closely to the mouse pointer (which is actually separate to the screen contents). So when you drag windows around in Ubuntu 20.04 they will stick to the mouse pointer more closely.

Display scaling was wasting megabytes of memory

It was just trying to store more detail than actually exists in the original wallpaper image. It doesn’t now, but there’s a chance similar mistakes are still lingering elsewhere in the code. So this is the beginning of an ongoing effort to find places where display scaling above 100% might impact performance.

Moving the mouse no longer involves JavaScript

Executing JavaScript isn’t objectively slow, but it is much slower than not executing JavaScript. Since we can avoid it, we now do. So CPU usage and battery usage will be a little lower while you whisk the mouse (or touchpad) around.

Opening or closing the icon grid is now quicker to respond

GNOME Shell is a complex system, kept as simple as possible through JavaScript. But sometimes changing one thing has unexpected side effects for another thing. What’s slightly mind bending is that JavaScript can execute concurrently across multiple frames and it’s not immediately obvious how many frames your JavaScript function is taking to execute. You hope it’s less than one, but sometimes it’s not.

Window sliding animations are now more efficient, smoother

GNOME Shell is built on Mutter via the Clutter toolkit. The Clutter toolkit started as a separate project but is now maintained inside Mutter.

One of the most performance sensitive parts of Clutter is when any GUI element gets “reallocated” through a “relayout” cycle. This involves walking through all the GUI elements and figuring out their size and position. Once that is known you can redraw individual elements more efficiently without involving their relatives. The problem is when GNOME Shell joins the party it adds some allocation functions written entirely in JavaScript, and that’s slower than the same kind of functions written in C (like Clutter/Mutter is). And we can’t easily change that because GNOME Shell GUI itself is written in JavaScript, so its allocation functions must be too.

What we can change is how often these allocations happen. And that’s what changing some animations from using x/y properties to translation-x and translation-y properties does. The latter means no reallocations need to happen so all that executing of JavaScript doesn’t need to happen, at least not in the middle of animations. So they’re now more CPU-efficient and should appear smoother. Just tap your Super key (the Windows key) to find out.

The icon spring/swarm animation is now more efficient, smoother

Even better than it was in Ubuntu 19.10. This was done using the same approach as in the above paragraph.

Relayouts are now more efficient

If an ancestor doesn’t want to be involved in relayouts, now it isn’t. This doesn’t directly improve performance noticeably, yet, but the new API will make it easier to solve more performance issues in future.

When multiple separate things are changing on screen, performance is now better (sometimes)

In 3.36, upstream Mutter introduced a new feature to draw multiple parts of the screen separately instead of merging them all into a single draw. The problem was this actually performed slower than 3.34 when the number of things increased. So we introduced a fix to make it perform comparatively to 3.34.

GJS is significantly more efficient now

GJS is the glue between GNOME Shell and the (Mozilla) JavaScript engine. It was found to contain a bug that would repeatedly execute the same code during some animations. That’s now fixed for all GNOME 3.36 systems.

Although Canonical found the bug and prototyped the first fixes, the final fix was provided by Philip Chimento. Thanks!

“But I still have performance issues”

We know some issues are still not solved. GNOME Shell’s performance will continue to improve in future releases. But don’t assume anyone else sees the same problems as you do. If you find something that’s not quite fast enough then please let us know by running this command to open a bug:

ubuntu-bug gnome-shell

We look forward to making you even happier in future releases.


Thank you for all the hard work. Really noticeable on my htpc’s single 4k screen set up. Almost on par with Unity.

My laptop setup however is still laggy due to using 3 displays with slightly different refresh rates and scaling factors (I can only use wayland here). I believe a fair amount of work has been done on this particular scenario but not yet landed. Any idea of whether 3.38 will finally address this?

1 Like

Love it when the latest desktop implementation catches up with a deprecated one.


I was really waiting for this post :slight_smile: It became one of the release highlights of every new version for me.

Now to something else. I’m physicist and I just handed in my phd thesis. Well almost, anyway, I do will have some time in the future to do stuff and I’m thinking if I could help with this by trying to provide some measurements. The interesting part here is of course how can I measure e.g. delay and animation stuttering and so on. Now I don’t have a tone of too expensive equipment but I’m thinking of putting something together, where I use the 60Fps camera of my smartphone to make recordings of my screen, then use a motor, or some trigger to press a certain button and try to record the response time and of and the smoothness of the animation.

I do have to think about this more, but my questions are:

  1. Would/could this help, if yes what would help?
  2. Are you doing this already if yes? You have some suggestions for a home build setup? I would like to keep it simple so people could rebuild this at there home as well.

Thank you for all the great work.
I am not going to lie, I still miss Unity from time to time (specially the HUD), but now I feel at home on Gnome Shell and that’s in not small part thank to the hard work done by Ubuntu devs over the last couple of years.

@msdeiseroth Congrats on your thesis. I am a physicist too and I can tell what a difficult time the thesis preparation is. It gets better! Good luck in your dissertation! :slight_smile:
I would also love to be able to help. I have noticed some performance problems (discussed on another topic and on launchpad) and it is always difficult to quantify an slight lack of smoothness.

It seems like GNOME is now performing better when there is high disk load. Was this also part of your work?

Christian Hergert did tons of profiling on the hunt for blocking IO and the like:

I believe quite a bit of that work has already landed.


@copong: The problem with poor multi-monitor performance in Wayland sessions is being tracked here. We (upstream and myself) hope that will be fixed this year.

@msdeiseroth: If you want to build a camera rig for measuring performance then it might be a good idea to use a higher frame rate than 60Hz. A simple and cheap solution is the PlayStation Eye camera (originally for the PS3) as that goes up to 187Hz in Linux. I used it a few years ago to measure Mir. If you were just measuring smoothness of an animation, you don’t need a camera for that as you could make a screen recording and assess positions in the video file, no camera required.

Although… if your screen is around 60Hz and the camera is an exact multiple of that then actually a 60Hz or 120Hz camera might be easier to reason about as you can just count frames.

@merlijn-sebrechts, @ppd: I have not investigated the relation to high disk load but yes I am familiar with that problem. Certainly the above link shows other people worked on it. My personal theory is that it was partly a problem in the 5.3 kernel, fixed in 5.4. Because the same issue suddenly appeared in Ubuntu 18.04 around the same time it got the 5.3 kernel. Or maybe Christian Hergert did find the main issues, I don’t know.


Thank you for your hard work and very interested information!

Anyway, could you give me permission to translate there articles (include for 19.04, 19.10) to Japanese?

1 Like

@mitsuya: Yes, feel free.

1 Like

Thanks for the hint with the playstation eye camera, I might give it a try. However is that needed? As my screen has 60Hz, I’m not gonna miss any frame. I imagine [Moire Patters]
(é_pattern) to be a problem tough.

If you were just measuring smoothness of an animation, you don’t need a camera for that as you could make a screen recording

Okay, but is that reliable? I sometimes have the impression that, depending on my overall pc load, the whole machine gets into stuttering and if the screen recorder suffers from the same I wouldn’t see this. Also I would like to trhough a bit more statistics on the whole topic. Basically like everything-you-know-about-latency-is-wrong suggested.

When I think about it, the biggest problem I would have right now is synchronization.

I like how thorough and careful you are…

Okay, but is that reliable? I sometimes have the impression that, depending on my overall pc load, the whole machine gets into stuttering and if the screen recorder suffers from the same I wouldn’t see this.

If the screen recorder slows down from 60Hz to 30Hz you would probably notice that. My suggestion of using a screen recorder was only to check spatial smoothness. It can’t be used for everything.

So yes, if it is convenient then using a camera that’s the same frame rate as your monitor should work fine. It’s very handy being able to match up frames one-to-one. That’s only going to fail if they are slightly different like 59.95Hz and the other is 60.00Hz. In such a case you would get a glitch or mismatch every 20 seconds.


That’s only going to fail if they are slightly different like 59.95Hz and the other is 60.00Hz

I think I just have to give it a try. What the problems are, you realize up on doing.

On the subject of screen recording, I have a magewell HDMI USB 3 capture card which I often use when reporting bugs. Here’s an example of the typical recording.

Would that be useful for capturing timings? It’s pretty reliable at capturing 60fps at 1080p from anything.

Why is GNOME using javascript as an interpretation layer for the mouse and gestures to begin with? I get that it is more easily extendable but I would think something so intimately tied to performance would be written using something a bit more efficient?

1 Like

Thanks! I uploaded.

1 Like

Unity vs gnome rabbit hole discussion. I reckon we all have our preferences. It’s a shame Unity 7 can’t be waylandified, but gnome has also come a long way since 17.10, and certainly a fair amount of it is due to Canonical getting involved in gnome again (among many contributors) and specifically @vanvugt crusade for performance.


Just updated GS+Mutter to 3.36.2 in Focal.
@vanvugt : could you give the right answer between the two next options ?

  1. overview windows tiling animation is slightly faster now
  2. my eyes are tired and I should go to sleep
    Thanks. :crazy_face:

The overview animation performance work was finished in 3.35.91 so it’s been done for some time. If you see any further improvement in 3.36.2 then great, but I don’t know why that would be.

On a 4k monitor, firefox playing 4k youtube video stutters… whereas in Unity it is smoooth.