How Unity, Compiz, GNOME Shell & KWin Affect Performance

[Wyatt]

The release quality of a rc1 of Linux is equivalent to a pre-alpha of any other software.

So you're saying pre-alpha means beta in your world...

Michael, I think you mentioned that Metacity isn't a compositing WM in the article... might want to fix that.

It's pretty interesting that the oldest Gnome WM and KWin are the most resilient. I guess investing in stability has tangible benefits! :3

[bleubugs]

Could you try against E17 composite manager (trying with both Software and OpenGL would be interesting to know also) ?

[mirv]

I'm curious how E17 would go here as well, with massive disclaimers that while the EFL has just had another bugfix release, E17 itself is still "in the works". Going the whole hog with an E16 comparison too would be good.

[ebassi]

gnome-shell/mutter, unlike the other compositing window manager tested here, is vblank-locked to 60 fps.

also, gnome-shell/mutter does not unredirect fullscreen applications - meaning it'll still composite fullscreen apps like games.

these two issues combined explain a huge chunk of the drop in fps.

[damg]

gnome-shell/mutter, unlike the other compositing window manager tested here, is vblank-locked to 60 fps.

also, gnome-shell/mutter does not unredirect fullscreen applications - meaning it'll still composite fullscreen apps like games.

these two issues combined explain a huge chunk of the drop in fps.

So essentially, gnome-shell in its current form is a step backwards for Linux gaming (and other fullscreen OpenGL apps like Blender)?

[ebassi]

So essentially, gnome-shell in its current form is a step backwards for Linux gaming (and other fullscreen OpenGL apps like Blender)?

currently, and if you want to output more frames than your display can actually render, then yes. there's nothing implicitly wrong in the architecture or the implementation, though - and using the refresh rate of the monitor is always the right choice to avoid burning through your GPU and battery life. so it's going to require some work, but it's going to get fixed.

[BlackStar]

So essentially, gnome-shell in its current form is a step backwards for Linux gaming (and other fullscreen OpenGL apps like Blender)?

Why would you wish run Blender at more fps than your monitor can handle?

[rewind]

And referring to the tests that's why I'm stuck at gnome-shell in forced fallback mode and with compiz running. It's not only games, it's HD videos and flash also. Not always less frames per sec., but sluggish and choppy motion with mutter. That's with the latest catalyst.
I think the best way to avoid such problems /with display manager/ is to start every fullscreen application like games in new x-server display.

[damg]

currently, and if you want to output more frames than your display can actually render, then yes. there's nothing implicitly wrong in the architecture or the implementation, though - and using the refresh rate of the monitor is always the right choice to avoid burning through your GPU and battery life. so it's going to require some work, but it's going to get fixed.

You're right, it does make sense to sync to vblank if you can consistently generate more FPS than your monitor refresh rate; but at this point I was referring to most games which are struggling to produce those 60 FPS in the first place; the vblank waiting is causing an extra hit in FPS.

It sounds like this extension that Carmack talked about might be useful; anyone know what that is?

[damg]

Why would you wish run Blender at more fps than your monitor can handle?

I don't. Your question assumes that Blender can always generate more FPS than the monitor can handle.