Metacity's compositing is too slow

[Alkis Georgopoulos]

[Impact]
Metacity's performance is about 2 times slower than it was in 14.04 version. It is a regression from previous LTS and impacts users with slow hardware.

[Test Case]
Run some performance checker like x11perf or glmark2, see the reporter's comments below for detailed info.

[Regression Potential]
This fix is tested by several users and seems to not have any regressions.

-----------------------------------------------------------------------------
I did the following benchmarks between `metacity --no-composite`, `metacity --composite`, and `compiz`, in Ubuntu 16.04.

First, I disabled vsync:
$ cat ~/.drirc
<device screen="0" driver="dri2">
    <application name="Default">
            <option name="vblank_mode" value="0"/>
    </application>
</device>

Then I ran glxgears as follows:

$ metacity --no-composite --replace & sleep 5 && glxgears & sleep 20 && killall glxgears
29564 frames in 5.0 seconds = 5912.721 FPS
29729 frames in 5.0 seconds = 5945.777 FPS

$ metacity --composite --replace & sleep 5 && glxgears & sleep 20 && killall glxgears
10366 frames in 5.0 seconds = 2073.057 FPS
10194 frames in 5.0 seconds = 2038.702 FPS

$ compiz --replace & sleep 5 && glxgears & sleep 20 && killall glxgears
37633 frames in 5.0 seconds = 7522.813 FPS
37990 frames in 5.0 seconds = 7597.965 FPS

As a second set of benchmarks, I ran glxgears -fullscreen as follows:

$ metacity --no-composite --replace & sleep 5 && glxgears -fullscreen & sleep 20 && killall glxgears
1652 frames in 5.0 seconds = 330.296 FPS
1667 frames in 5.0 seconds = 333.281 FPS

$ metacity --composite --replace & sleep 5 && glxgears -fullscreen & sleep 20 && killall glxgears
886 frames in 5.0 seconds = 177.007 FPS
891 frames in 5.0 seconds = 178.099 FPS

$ compiz --replace & sleep 5 && glxgears -fullscreen & sleep 20 && killall glxgears
1830 frames in 5.0 seconds = 365.868 FPS
1847 frames in 5.0 seconds = 369.242 FPS

Normalized results (with compiz=100):
================================
Windowed:
metacity --no-composite: 78 FPS
metacity --composite: 27 FPS
compiz: 100 FPS

Full screen:
metacity --no-composite: 90 FPS
metacity --composite: 48 FPS
compiz: 100 FPS

So `metacity --composite` in this test was about 2 times slower than `metacity --no-composite` and about 3 times slower than `compiz`.

This test was done an "Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz" CPU, with the following embedded graphics card:
$ lspci -nn -k | grep -A 2 VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)
 Subsystem: Gigabyte Technology Co., Ltd Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [1458:d000]
 Kernel driver in use: i915

I'll upload more tests if I find anything newsworthy.

[Alkis Georgopoulos (alkisg)]

Ah, I forgot to include the results without a window manager as a comparison:

$ killall metacity & sleep 5 && glxgears -fullscreen & sleep 20 && killall glxgears
44884 frames in 5.0 seconds = 8976.656 FPS
44905 frames in 5.0 seconds = 8980.993 FPS

Normalized: 118 FPS, the fastest of all.

$ killall metacity & sleep 5 && glxgears -fullscreen & sleep 20 && killall glxgears
1743 frames in 5.0 seconds = 348.422 FPS
1713 frames in 5.0 seconds = 342.471 FPS

Normalized: 94 FPS, slower than compiz. That may be due to compiz not using the whole screen in glxgears -fullscreen; the drawing area didn't include the panels.

[Alkis Georgopoulos (alkisg)]

I run another set of benchmarks using x11perf.
I don't know how much they can help in pinpointing the issue(s), but they do show that `metacity --composite` is extremely slower than `metacity --no-composite` or `compiz`.

I'm attaching the output in LibreOffice Calc format, I think it's more readable that way.

An example line from the attached .ods file:
Test: 500x500 tiled rectangle (17x15 tile)
no WM: 772 (100 %)
metacity --no-composite: 699 (91%)
metacity --composite: 233 (30 %)
compiz: 688 (89 %)

The numbers are the repetitions, and inside the parentheses are the normalized values, with 100% being the highest.
The others are about 90% efficient, while `metacity --composite` is only 30% efficient, three times slower in that test.

I can also create a similar .ods for gtkperf, if anyone thinks that it will somehow help.

[Alkis Georgopoulos (alkisg)]

And here are some numbers for glxgears again (on another pc), but with xcompmgr and compton included.
The first column is the WM used, the second is the FPS for glxgears, and the third the FPS for glxgears -fullscreen:

no wm 221 15
metacity --no-composite 170 15
metacity --composite 83 7
compiz 225 15
xcompmgr 122 7
compton 102 7

`metacity --composite` is again about 3 times slower than no-wm and compiz.
With appropriate fixes, it should be able to reach at least the performance of xcompmgr, shouldn't it?

[Alkis Georgopoulos (alkisg)]

Here's another benchmark, with an SDL 2D game, teeworlds, running full screen:

no wm: 220 FPS
metacity --no-composite: 220
metacity --composite: 130
compiz: 218
xcompmgr: 130
compton: 129

I really think that the user's choices would be:
1) compiz, for every PC that supports it,
2) metacity --no-composite, for any PC that doesn't support compiz and that isn't able to spare 50%-80% of their FPS,
3) metacity --composite, ONLY for the minority of the PCs with graphics cards that can't run compiz and with so awesome CPUs that can spare 50-80% of their FPS. If you can find an example of such a PC, please let me know, currently I don't know of any. I do know of thousands of examples in category (2) though.

Since `metacity --composite` is so much slower, affecting all apps and actions from simple drawing to scrolling to moving around windows to watching videos to game playing etc,
I'd like to again ask you to consider NOT making (3) the preferred session for gnome-flashback for 16.04.

I.e. gnome-flashback-compiz could be the default (proposed one),
and gnome-flashback-metacity the non composited version,
with the --composite option only available as a gsetting for the minority of the people that would need it.

Thanks!

[Alkis Georgopoulos (alkisg)]

Yet another benchmark, glmark2, in a very recent core i5 client.

Scores:
No WM: 2058
marco --no-composite: 1894
compiz : 1878
metacity --no-composite: 742
xcompmgr: 716
marco --composite: 708
metacity --composite: 441

In an ideal world, gnome-flashback would support compiz first, then `metacity --no-composite` but with the speed of `marco --no-composite`.

They're 4-5 times faster than the proposed `metacity --composite`!!!

/me will definitely ask the Mate people if they still support `marco --no-composite`...

[Alberts Muktupāvels (muktupavels)]

Any chance that you could track down version when it started to be slow? Was composite already slow in previous LTS?

[Alkis Georgopoulos (alkisg)]

> Any chance that you could track down version when it started to be slow?
> Was composite already slow in previous LTS?

Initial tests show that metacity had about the same performance as marco in 12.04 and in 14.04.
In those versions, `metacity (or marco) --composite` performs only about 60% as well as `metacity --no-composite`,
while `compiz` performs about the same as `metacity --no-composite`.
glxgears example:
no-wm: 394.117
compiz: 393.603
metacity --no-composite: 403.858
metacity --composite: 239.124
marco --no-composite: 404.455
marco --composite: 242.672

Unfortunately in 16.04 it got a whole lot worse, for example:
no-wm: 469.506
compiz: 467.071
metacity --no-composite: 277.188
metacity --composite: 122.936
marco --no-composite: 464.281
marco --composite: 287.314
xcompmgr: 291.990

Now `marco --composite` is still at 60%, while `metacity --composite` is now at only 25% of the optimal performance.
But note that `metacity --no-composite` is also a whole lot worse than `marco --no-composite`.

Alberts do you want me to try with non-LTS releases as well?

These tests were made by running a plain `xinit` (which gives a simple xterm) on top of a usual Ubuntu gnome-flashback installation, while also installing marco there.

[Alkis Georgopoulos (alkisg)]

To sum up, two problems:

1) `metacity (and marco) --composite` in 12.04 and 14.04 had only 60% of the compiz performance.
2) `metacity` (both composite and no-composite) got a lot slower in 16.04, at 60% and 25% respectively of the compiz performance.

[Alberts Muktupāvels (muktupavels)]

Thanks! No, you don't need to test anything now...
I found why it is slow, but it is not something I could revert - I need to find proper solution.

[Alberts Muktupāvels (muktupavels)]

Any chance you could test this branch:
https://git.gnome.org/browse/metacity/log/?h=wip/test-3-18

It should restore speed at least in no-composite case. Please test and report any regression you see.

[Alkis Georgopoulos (alkisg)]

Hi Alberts,

I tried applying the latest 13 commits from the test-3-18 branch on top of Xenial's metacity.

If my benchmarks were correct, it made things even slower.

glmark2 score:
xenial-metacity --no-composite: 311
test-3-18-metacity --no-composite: 154
xenial-marco --no-composite: 902

I.e. now it's 6 times, rather than 3 times, slower than marco...

Can we use marco instead? Doesn't it additionally have CSD support?

Or, could end users of gnome-flashback-session decide to install and use marco instead of metacity without bumping into major issues?

[Alberts Muktupāvels (muktupavels)]

On Fri, Apr 15, 2016 at 12:31 PM, Alkis Georgopoulos <
<email address hidden>> wrote:

> I tried applying the latest 13 commits from the test-3-18 branch on top
> of Xenial's metacity.
>

Are you sure that all patches applied?

If my benchmarks were correct, it made things even slower.
>
> glmark2 score:
> xenial-metacity --no-composite: 311
> test-3-18-metacity --no-composite: 154
> xenial-marco --no-composite: 902
>

glmark2 segfaults for me, but glxgears gives me following results:
no-composite: ~750 FPS vs. ~2380 FPS
composite: ~540 FPS vs. ~710 FPS

I.e. now it's 6 times, rather than 3 times, slower than marco...
>

If that is true then I have no idea how this could happen... At least one
of problem was that all frame/decoration windows was created with 32bit
visual for transparency (even when running without compositing manager). If
we look from no-composite side than it is almost only about revert of that
change...

Can we use marco instead? Doesn't it additionally have CSD support?
>

In Flashback session? No - Flashback will never use marco.

Or, could end users of gnome-flashback-session decide to install and use
> marco instead of metacity without bumping into major issues?

It should be possible to install, but I have no idea if there will be
problems...

[Alkis Georgopoulos (alkisg)]

Alberts, I'm sorry, the (new) client that I tested with is giving me very inconsistent results, even by just rebooting it, and I'm not going to use it in benchmarks again in the future. It's a 3-year-old AMD-based laptop; maybe the problem is in the radeon driver or in its power states, anyway, please ignore my results in comment #11.

I tested again with the client from comment #7 (an old intel 8xx based laptop), and I reproduced what you said, i.e. that your patches indeed made metacity fast again:

no-wm: 481.234
compiz: 473.248
xenial-metacity --no-composite: 294.148
xenial-metacity --composite: 177.516
fixed-metacity --no-composite: 470.791
fixed-metacity --composite: 283.285
marco --no-composite: 471.382
marco --composite: 286.939
xcompmgr: 291.370

I also confirmed the performance increase in the i5 desktop from comment #5.

@Alberts, thank you very much, you're awesome!

@Dmitry, could we please get those patches in Xenial?

[Dmitry Shachnev (mitya57)]

I tested the wip/test-3-18 branch and got the following bug:

At some point (when I was switching windows?) the screen became completely black, and only when the windows repainted themselves they started to become visible. I.e. first the window after the mouse became again visible, then when I pressed Alt-Tab, the other window became visible, then the clock on the panel (because the minute changed), etc.

Unfortunately I was not able to take a screenshot. It is not reproducible, I got it only once so far. I never got this bug before, can it be a regression of that branch?

[Alberts Muktupāvels (muktupavels)]

On Fri, Apr 15, 2016 at 8:39 PM, Alkis Georgopoulos <
<email address hidden>> wrote:

> I tested again with the client from comment #7 (an old intel 8xx based
> laptop), and I reproduced what you said, i.e. that your patches indeed
> made metacity fast again:
>
> no-wm: 481.234
> compiz: 473.248
> xenial-metacity --no-composite: 294.148
> xenial-metacity --composite: 177.516
> fixed-metacity --no-composite: 470.791
> fixed-metacity --composite: 283.285
> marco --no-composite: 471.382
> marco --composite: 286.939
> xcompmgr: 291.370
>

Thanks for testing! Good to know that performance has increased. :)

@Dmitry, could we please get those patches in Xenial?
>

No, it is not ready. Composited case will have few regressions (in
wip/test-3-18 branch). One I have already fixed localy, but there are at
least two other things - I had problems with rounded corners and alt-tab
dialog.

Dmitry, do we have time to get new upstream bug fix release in xenial?

[Alberts Muktupāvels (muktupavels)]

On Fri, Apr 15, 2016 at 8:48 PM, Dmitry Shachnev <email address hidden> wrote:

> I tested the wip/test-3-18 branch and got the following bug:
>
> At some point (when I was switching windows?) the screen became
> completely black, and only when the windows repainted themselves they
> started to become visible. I.e. first the window after the mouse became
> again visible, then when I pressed Alt-Tab, the other window became
> visible, then the clock on the panel (because the minute changed), etc.
>

Did you test in xenial and/or in debian session?

Unfortunately I was not able to take a screenshot. It is not
> reproducible, I got it only once so far. I never got this bug before,
> can it be a regression of that branch?
>

Maybe.

[Alkis Georgopoulos (alkisg)]

> only when the windows repainted themselves they started to become visible.

I've seen that in the past about 5 times in the last 2 years.
I don't remember which LTS gnome-flashback version I was using.

[Alberts Muktupāvels (muktupavels)]

Ok, I have pushed all changes to master and gnome-3-18 branches.

Dmitry and Alkis, can you both re-test gnome-3-18 branch? After that I will make 3.18.4 release.

[Alkis Georgopoulos (alkisg)]

I'm having a hard time applying all the last e.g. 20 upstream commits to the Xenial tree.

@Dmitry, since you'll be merging the upstream with the Ubuntu tree anyway in order to test it youself,
would it be possible to push the result somewhere, e.g. in launchpad,
or publish a .deb in a PPA,
so that it's easier for me to test it?

In general, it'd be nice to have a launchpad recipe that builds upstream gnome-flashback + ubuntu packaging to some PPA, so that we can test things more easily.

E.g. this is what I have for testing LTSP upstream:
https://code.launchpad.net/~alkisg/+recipe/ltsp-daily

[Alberts Muktupāvels (muktupavels)]

Alkis, I built new packages from gnome-3-18, but did not test... Use at your own risk.

[Dmitry Shachnev (mitya57)]

> Dmitry and Alkis, can you both re-test gnome-3-18 branch? After that I will make 3.18.4 release.

Unfortunately there is a crash with the latest gnome-3-18 branch (commit b299d7d).

Steps to reproduce:

1) Open some windows
2) Click on "Show Desktop" icon to hide them
3) Press Alt+Tab or Super+Tab

The stacktrace is attached.

[Alkis Georgopoulos (alkisg)]

Alberts I'm mostly using i386 installations so I could only test amd64 in a VM.
I did saw a performance improvement there, but it wasn't as big as in the real hardware case...

[Alberts Muktupāvels (muktupavels)]

https://launchpad.net/~albertsmuktupavels/+archive/ubuntu/metacity-3-18

[Alkis Georgopoulos (alkisg)]

Thank you Alberts, yup that indeed increased the performance a lot:

xenial-metacity --no-composite:
30407 frames in 5.0 seconds = 6081.219 FPS

ppa-metacity --no-composite:
37147 frames in 5.0 seconds = 7429.385 FPS

marco --no-composite:
37146 frames in 5.0 seconds = 7429.081 FPS

Alberts, Dmitry, please also note that Ubuntu now allows publishing upstream microreleases:
https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases

For example, for LTSP, I plan on maintaining a branch with bug fixes only, and I'll be SRUing it regularly to 16.04, without having to go through the bureaucracy of filing one SRU for each bug fix separately.

Maybe something similar could be done for flashback? :)

In any case, thanks a lot, you guys are awesome!

[Alberts Muktupāvels (muktupavels)]

Alkis, do you use metacity daily? We need to know if my changes does not introduce other regressions.

[Alkis Georgopoulos (alkisg)]

Yup, I'm using your 1:3.18.3+git20160418-1ubuntu3 metacity many hours per day on my main work PC.
i386, Xenial, Core i5-4440 @ 3.10 GHz, 8 GB RAM.

I haven't seen any regressions so far, and I cannot even reproduce the issue Dmitry reported; although I've seen some recent commits of yours that might have solved it...

[Martin Pitt (pitti)]

Hello Alkis, or anyone else affected,

Accepted metacity into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/metacity/1:3.18.4-0ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Martin Pitt (pitti)]

Dmitry, please upload this to yakkety as well, otherwise this cannot land in -updates.

[Alkis Georgopoulos (alkisg)]

I just tried it and it indeed solves the performance issues:

Old version 1:3.18.3-1ubuntu3:
$ vblank_mode=0 glxgears
27418 frames in 5.0 seconds = 5483.539 FPS

New version 1:3.18.4-0ubuntu0.1:
$ vblank_mode=0 glxgears
39851 frames in 5.0 seconds = 7970.179 FPS

[Launchpad Janitor (janitor)]

This bug was fixed in the package metacity - 1:3.18.4-1ubuntu1

---------------
metacity (1:3.18.4-1ubuntu1) yakkety; urgency=medium

  * Merge with Debian unstable, remaining changes:
    - debian/metacity-common.links: Show keybindings in Unity control center.
    - debian/metacity-common.gsettings-override: Change the default theme to
      Ambiance.
  * Drop all patches, applied upstream.
  * The new release fixes LP: #1566157, #1573478.

 -- Dmitry Shachnev <email address hidden> Tue, 26 Apr 2016 14:21:16 +0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package metacity - 1:3.18.4-0ubuntu0.1

---------------
metacity (1:3.18.4-0ubuntu0.1) xenial; urgency=medium

  * New upstream bugfix release.
    - Fixes crashes (LP: #1573478).
    - Fixes performance regressions (LP: #1566157).
  * Drop both patches, applied upstream.

 -- Dmitry Shachnev <email address hidden> Sun, 24 Apr 2016 21:37:01 +0300

[Martin Pitt (pitti)]

The verification of the Stable Release Update for metacity has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.