Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 32

Thread: How Unity, Compiz, GNOME Shell & KWin Affect Performance

  1. #11
    Join Date
    Jan 2009
    Location
    Columbus, OH, USA
    Posts
    323

    Default

    Quote Originally Posted by allquixotic View Post
    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

  2. #12
    Join Date
    May 2011
    Posts
    14

    Default Please try E17

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

  3. #13
    Join Date
    Oct 2007
    Posts
    912

    Default

    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.

  4. #14
    Join Date
    May 2011
    Posts
    2

    Default wrong "benchmark"

    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.

  5. #15
    Join Date
    Dec 2010
    Posts
    18

    Default

    Quote Originally Posted by ebassi View Post
    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)?

  6. #16
    Join Date
    May 2011
    Posts
    2

    Default

    Quote Originally Posted by damg View Post
    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.

  7. #17
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,144

    Default

    Quote Originally Posted by damg View Post
    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?

  8. #18
    Join Date
    Jun 2010
    Posts
    34

    Default

    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.

  9. #19
    Join Date
    Dec 2010
    Posts
    18

    Default

    Quote Originally Posted by ebassi View Post
    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?

  10. #20
    Join Date
    Dec 2010
    Posts
    18

    Default

    Quote Originally Posted by BlackStar View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •