js/ui: Choose some actors to cache on the GPU (!73) · Merge Requests · GNOME / gnome-shell

js/ui: Choose some actors to cache on the GPU

Flag some actors that are good candidates for caching in texture memory (what Clutter calls "offscreen redirect"), thereby mostly eliminating their repaint overhead.

This isn't exactly groundbreaking, it's how you're meant to use OpenGL in the first place. But the difficulty is in the design of Clutter which has some peculiarities making universal caching inefficient at the moment:

Repainting an offscreen actor is measurably slower than repainting the same actor if it was uncached. But only by less than 100%, so if an actor can avoid changing every frame then caching is usually more efficient over that timeframe.
The cached painting from a container typically includes its children, so you can't cache containers whose children are usually animating at full frame rate. That results in a performance loss. This could be remedied in future by Clutter explicitly separating a container's background painting from its child painting and always caching the background (as StWidget tries to in some cases already).

So this commit selects just a few areas where caching has been verified to be beneficial, and many use cases now see their CPU usage halved:

One small window active...... 10% -> 7% (-30%)
...under a panel menu........ 23% -> 9% (-61%)
One maximized window active.. 12% -> 9% (-25%)
...under a panel menu........ 23% -> 11% (-52%)
...under a shell dialog...... 22% -> 12% (-45%)
...in activities overview.... 32% -> 17% (-47%)

(on an i7-7700)

Also a couple of bugs are fixed by this:

https://bugzilla.gnome.org/show_bug.cgi?id=792634
https://bugzilla.gnome.org/show_bug.cgi?id=792633

Flag some actors that are good candidates for caching in texture memory
(what Clutter calls "offscreen redirect"), thereby mostly eliminating
their repaint overhead.

This isn't exactly groundbreaking, it's how you're meant to use
OpenGL in the first place. But the difficulty is in the design of
Clutter which has some peculiarities making universal caching
inefficient at the moment:

* Repainting an offscreen actor is measurably slower than repainting
   the same actor if it was uncached. But only by less than 100%,
   so if an actor can avoid changing every frame then caching is usually
   more efficient over that timeframe.

* The cached painting from a container typically includes its children,
   so you can't cache containers whose children are usually animating at
   full frame rate. That results in a performance loss.
     This could be remedied in future by Clutter explicitly separating a
   container's background painting from its child painting and always
   caching the background (as StWidget tries to in some cases already).

So this commit selects just a few areas where caching has been verified
to be beneficial, and many use cases now see their CPU usage halved:

```
One small window active...... 10% -> 7% (-30%)
...under a panel menu........ 23% -> 9% (-61%)
One maximized window active.. 12% -> 9% (-25%)
...under a panel menu........ 23% -> 11% (-52%)
...under a shell dialog...... 22% -> 12% (-45%)
...in activities overview.... 32% -> 17% (-47%)
```
(on an i7-7700)

Also a couple of bugs are fixed by this:

https://bugzilla.gnome.org/show_bug.cgi?id=792634<BR>
https://bugzilla.gnome.org/show_bug.cgi?id=792633

Edited Apr 19, 2018 by Daniel van Vugt