Is window moving/resizing/minimizing actually faster in Gnome 2.14.0?

According to this review of Gnome 2.14.0

Metacity’s most noticeable improvement is its speed — specifically, a faster redraw of windows when they are resized, moved, or minimized.

There were some changes that should have made it a little faster in 2.12, but the article seems to be contrasting 2.14.0 to 2.12.x. If the reviewer was using AIGLX or GLX and the compositor that’s part of Metacity or Compiz then I would know exactly where this claim is coming from, but it doesn’t look like he is using either from reading the rest of the article. So, I was actually surprised at this claim. I had previously been worried that I had actually slowed it down a little with my changes — but this is definitely making me feel better 🙂 Now, there were a lot of changes that affected moving and resizing, but did they really make that much difference? Or is this an underlying speed increase from pango and gtk (which we use to draw the frames), and I just didn’t notice because I got the small incremental improvements as they were made when Federico et al. beat the performance problems out of those libraries?

While I’m on the subject of Metacity, I recently came up with a highlight list of improvements over 2.12.x, and I thought others might be interested in it:

  • Edge resistance when moving windows (not magnetism; too bad I didn’t notice this mistake in the release notes until too late)
  • Dozens and dozens of moving, resizing, and placement bugs fixed
  • Raise-on-click is a pref now for all you mouse/sloppy focus users
  • Display hostname in titlebar for remote X clients
  • Fixed multiple bugs with multi-head support (which probably eclipsed the xinerama bug fixes done)
  • Real vertical and horizontal maximization exist now
  • Make Alt-Esc really behave as “switch between windows immediately” including showing minimized windows
  • Don’t allow focus stealing from terminals (sadly, some consider this a misfeature; will probably be an option in 2.16.x and be off by default — hopefully that won’t disappoint a certain LWN editor)
  • Real support for –disable-gconf for e.g. embedded systems
  • An –enable-compositor mode that should be workable “if you’re the right kind of person”; not built by default (however, it will be compiled in to FC5 and enable-able & diable-able on the fly with gconf though…)
  • Tons of other miscellaneous bug fixes

4 thoughts on “Is window moving/resizing/minimizing actually faster in Gnome 2.14.0?”

  1. Was any work done in this round to synchronize the drawing of window contents with the frames? Keith Packard once gave a demo that showed with- and without frame synchro, and apparently even though it slows down the output, everybody *swears* it looks faster, probably because you can’t see an intermediate state (frame drawn, content not yet updated). Just a thought. 🙂

  2. > Raise-on-click is a pref now for all you mouse/sloppy
    > focus users

    This is just soo nice!

  3. Oh, so this windows misplacement is metacity’s focus stealing prevention fault? I hate when mplayer launched from terminal appears _below_ all other windows. Or when I click on Gajim trayicon and message window is mapped below other windows.
    They should appear above all windows but without focus.

  4. Ken: Now that you bring it up, I do remember that there was a bug fixed with the code that is supposed to synchronize the drawing of the window contents with the frames, so I guess that might be related. There was also another bug to avoid attempting updates when the movement that had occurred was 0 (which was actually just meant as an unrelated bug fix as opposed to an optimization, though I guess it can be both). Other than the huge rewrite of constraints.c (every move has to go through that constraints code), those are the only things I can find — but hey, if that makes it faster for someone, I guess I should just be happy. 🙂

Comments are closed.