Comment 33 for bug 1690719

I also experience this issue on a Thinkpad W540, with an i7-4900MQ and running Fedora 22 (with mesa from git).

I agree with Clement that this has been a bug for a long time on Gnome 3 - various shell actions can stall the entire compositor. The Wayland implementation just makes it a lot worse, because the mouse cursor is included in the repaint loop, but it is a problem even on X.

Things that drop me to 30fps or less on gnome-shell Wayland:
- Maximized GTK2 app (using xwayland)
- Activities icon chooser (15fps or worse)
- Opening gnome-control-center via the user menu (0.2s pause, it was several seconds on gnome 3.14)

Opinions:
- JS probably shouldn't be allowed to block the compositor, ever, because of the possibility of GC pauses.
- Graphically heavy things like the activities menu should probably be a compositor client, rather than happen directly in the compositor.

FWIW I have none of these problems in Weston.