Package Details: mutter-performance 3.34.3+1+g78a45e181-1

Git Clone URL: (read-only, click to copy)
Package Base: mutter-performance
Description: A window manager for GNOME | Attempts to improve performances with non-upstreamed merge-requests and frequent stable branch resync
Upstream URL:
Licenses: GPL
Groups: gnome
Conflicts: mutter
Provides: mutter, mutter-781835-workaround
Replaces: mutter-781835-workaround
Submitter: Terence
Maintainer: Terence (Saren)
Last Packager: Terence
Votes: 43
Popularity: 0.41
First Submitted: 2019-07-09 09:35
Last Updated: 2020-01-11 18:26

Dependencies (22)

Required by (14)

Sources (4)

Pinned Comments

Terence commented on 2019-06-10 19:14

If you are getting cogl/cogl/ ERROR: dependency glesv2 not found. or similar, install

Saren commented on 2018-08-30 14:52

If you are getting errors like fatal: bad revision '73e8cf32' while building this package, refer to PKGBUILD and see which patches caused this. Then, go to the related URLs, replace the commit hashes. If there are conflicts, comment out the patches.

Please notify me in comment section if this happens.

The optional performance patches are by default enabled.

A package for gnome-shell performance patches:

If applicable, $ touch ~/.i_dont_use_wayland_on_gnome and $ touch ~/.i_dont_use_multiple_keyboard_layouts for extra patches.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

TheAifam5 commented on 2019-12-29 02:47

Just for info when someone gets same issue....

'!762' throws an error while compiling tests, when all (except '!429') are enabled:

/usr/bin/ld: /tmp/ in function `clutter_actor_continue_paint':
<artificial>:(.text+0x820f): undefined reference to `clutter_stage_get_no_clear_hint'
/usr/bin/ld: /tmp/ in function `clutter_stage_set_property':
<artificial>:(.text+0x7af0): undefined reference to `clutter_stage_set_no_clear_hint'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

'!429' throws an error, when all are enabled:

Merging latest commits for !429...
Found ^ for !429
fatal: bad revision '^..'

'!724' works for me, when all (except '!429' and '!762') are enabled

Terence commented on 2019-12-28 20:09

@glitsj16 @nik9 Yeah, !724 would require a manual rebase I think. Disabling it by default. I also updated !762.

glitsj16 commented on 2019-12-11 00:40

@Terence Getting the same error as @nik9 for !724, and I don't use the test part. It might be related to (recent changes), not entirely sure.

On a similar vain, pick_mr '!762' e9ba9dc2 'merge' produces fatal: bad revision 'e9ba9dc2' I could fix this by changing to: pick_mr '!762' 'renderer-native: Check that frame_info != NULL' from

Terence commented on 2019-12-10 22:29

@nik9 I think this is just the test part? It should work if you use makepkg --nocheck

nik9 commented on 2019-12-10 19:22

FAILED: clutter/clutter/ when !724 is enabled

Terence commented on 2019-11-16 23:08

@glitsj16 Forgot to remove it from the array. It was merged and then cherry-picked to gnome-3-34.

glitsj16 commented on 2019-11-16 22:12

What's up with !909? In the history I see it was added [url=]here[/url], subsequently got [url=]removed[/url] but it is still in the [color=blue]_merge_requests_to_use[/color] array...

I tried reviving !909 in its prior form (pick_mr '!909' b1b7c597^..765c8a3a 'merge') but that throws a [color=crimson]fatal: bad revision 'b1b7c597^..765c8a3a'[/color] message. When using it like [color=steelblue]pick_mr '!909' "x11-display: Don't unset the X11 focused window after setting one"[/color] (mind the double-quote to not break on the single quote inside the title) efe5bed5b is found for !909 and the build happily proceeds. Can someone confirm whether or not !909 should still be referenced in the array?

deezid commented on 2019-11-02 14:51

No issues here with !719 & !762. NVIDIA 440, 1080Ti, Manjaro

Terence commented on 2019-10-30 09:52

@Saren sorry but creating a file in your home like that is awful. What can be done instead as you mentioned is creating an ENV containing the PR the PKGBUILD would check and use.

Saren commented on 2019-10-30 06:01

Well, editing PKGBUILD every update VS creating a file once and forget it, I prefer the latter. Maybe I could make use of environment variables (/etc/environment) next update.