Package Details: mutter-performance 1:47.1.r2.g74cf8ac0f-2

Git Clone URL: https://aur.archlinux.org/mutter-performance.git (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: https://gitlab.gnome.org/GNOME/mutter
Licenses: GPL-2.0-or-later
Groups: gnome
Conflicts: mutter
Provides: libmutter-15.so, mutter
Submitter: Terence
Maintainer: Terence (Saren, saltyming)
Last Packager: saltyming
Votes: 78
Popularity: 0.186852
First Submitted: 2019-07-09 09:35 (UTC)
Last Updated: 2024-10-22 08:26 (UTC)

Required by (16)

Sources (4)

Pinned Comments

saltyming commented on 2022-03-22 09:37 (UTC) (edited on 2024-10-22 08:27 (UTC) by saltyming)

If you have a problem during any system update with mutter-performance & gnome-shell-performance, please install mutter & gnome-shell packages from the main repository and do full upgrade first, then build the performance packages later.

If you are using [gnome-unstable] and [extra-testing] repositories, use mutter-performance-unstable

The default patch list includes "Dynamic triple buffering(!1441)", "text-input-v1(!3751)".

Latest Dynamic triple buffering patch has several included MRs from the main development branch to achieve maximum performance.

To enable a specific MR in the Merge Requests List, add an line "_merge_requests_to_use+=('<MR number>')" at the end of PKGBUILD. (Because if you edit the line directly you can be able to end up with merge conflict upon updates.)

You can see some patches' git history here: https://git.saltyming.net/sungmg/mutter-performance-source/

Saren commented on 2018-08-30 14:52 (UTC) (edited on 2020-10-06 05:50 (UTC) by Saren)

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: https://aur.archlinux.org/packages/gnome-shell-performance/

Latest Comments

« First ‹ Previous 1 .. 41 42 43 44 45 46 47 48 49 50 51 .. 64 Next › Last »

deezid commented on 2019-01-31 10:07 (UTC)

@Terence, thanks for the explanation, compiling without the patch atm.

Terence commented on 2019-01-31 10:04 (UTC)

@deezid no problem and yes it is enabled by default. If you inspect the PKGBUILD at line 12 you can see there is a variable you can either enable or disable which controls if the patch is applied or not.

Terence commented on 2019-01-31 10:01 (UTC)

@calindan2013 Thanks for your insightful comment. I suggest you to simply stop trying it as you stated before 'the packages is useless.'

deezid commented on 2019-01-31 10:00 (UTC) (edited on 2019-01-31 10:01 (UTC) by deezid)

@Terence is revert.patch applied atm in latest PKGBUILD? Don't have any programming skills, sorry.

@calindan2013 what does slow mean? Dragging windows, scrolling in windows, or just the workplace switcher on the right while zooming in? Also more 30Hz slow (like stock 3.30 mutter) or "only" 60Hz (like the max on my 4K 27" anyway)

calindan2013 commented on 2019-01-31 09:57 (UTC)

still slow

deezid commented on 2019-01-31 09:55 (UTC)

@Terence, after applying the 3.30 117 patch, everything stays smooth without 168 applied. So problem is solved I guess? :)

Terence commented on 2019-01-31 09:52 (UTC)

@deezid do you feel the difference without the revert patch applied?

Terence commented on 2019-01-31 09:51 (UTC)

@DeadMetaler thanks, updated. @deezid Do you have a 1000Hz mouse? Also, try to drag the window around while playing a video with and without 168 and tell me how it feels, thanks.

deezid commented on 2019-01-31 09:46 (UTC)

@DeadMetaler, haha, just had the same idea!

deezid commented on 2019-01-31 09:45 (UTC)

Seems like with 168 applied in my "smoothness test" (playing YouTube in 4K in one windows, scrolling in another), everything stays smoother. Without 168 it becomes quite messy after a few seconds.

Another question, wondering if 117 applies at all? There are lots of messages before compiling about not being able to apply it? Why not use the 3.30 branch version of the patch instead? 9a466f28

« First ‹ Previous 1 .. 41 42 43 44 45 46 47 48 49 50 51 .. 64 Next › Last »