Created attachment 101341 [details]
Screenshot with the profile

I have looked into this a little bit and all the time is spent getting the pixbuf from the pixmap, and then scaling it.  You can speed this up a bit by using a faster filter for the scaling.  Of course this really reduces the quality of the scaled windows.

Would it make sense to create a thumbnail for the window much like we do for the icon?  This will create a bit more memory overhead, but if we are updating the window when idle it should draw the application switcher much faster as the window thumbnail will already be scaled.

Created attachment 102130 [details] [review]
an unfinished possible solution to this problem

This is the beginnings of an infrastructure to update a thumbnail of each window when idle.  It does the same thing that we do for the window icon.  I haven't figured out yet where I want to mark a window as needing a thumbnail update so right now the thumbnails never get updated.  This does solve the problem that minimized windows only show their icons in the tab switcher by just using the last thumbnail generated.  It is also just as fast as the normal alt+tab behavior.  I will try to finish it up this weekend, but would like comments if you have time to take a look.

Actually, the screenshot Fernando posted shows that a lot of the time is spent in libfb.so. What's going on is almost certainly that the X server is reading from the framebuffer.

To confirm this, try adding

    Option "XAANoOffscreenPixmaps"

to the "Device" section of xorg.conf.

If that makes it much faster, then framebuffer reading is the problem.

I am sorry, but I don't see where you get that information.  I see that more time is spent in scale_line called by pixops_process.  I would love to test with XAANoOffscreenPixmaps but that functionality is not implemented in the openchrome X driver, and I don't have the time to add it.

I did just notice that Fernando is using XAA and I am using EXA which could explain some of the discrepencies.  I do see the slowdown on my NVIDIA with RenderAccel also.  

I do like having the thumbnail rendered and stored because then you will still get a graphical display of minimized windows.  I do understand this is done at the expense of RAM.  I do like the image in alt+tab, however speed is a necessity here.  

I get this from this line:

    In file /usr/lib/xorg/modules/libfb.so       23.89  25.66

in the "Functions" pane, and from my experience which is that whenever compositors get really slow, it's almost always a case of reading from video memory. However, I just noticed that Fernando's profile only contains 113 samples, so we probably shouldn't believe it all that much.

The main drawback I see to caching the thumbnails is that it then won't be possible to update them live, but I don't otherwise have any strong opinions either way.

As Søren already said caching thumbnails wont work as you need to update it moreover we should be able to update them while we are doing alt+tab in real time like compiz guys do.

Pointing out that the bug is mostly about not dealing with graphics at all.

"(when the user is not interested on
seeing all the available windows, just to switch to the last-used one)"

So there should be a case for when the user just quickly types alt-tab to switch to the next window quickly. Metacity could wait a split second before trying to render the alt-tab graphics to catch this use case.

(In reply to comment #8)
> Pointing out that the bug is mostly about not dealing with graphics at all.

No, the reason it is slow is 100% to do with the graphics.
Currently to make the thumbnails the alt-tab does the following

a) Takes the backing store pixmap and turns it into a GdkPixbuf
b) Scales the GdkPixbuf
c) Puts it on the screen.

This requires 2 trips of copying a large amount of data between XServer and client. What it should do is this:

a) Take the XRender picture
b) Apply a scale on it
c) Draw it to the screen.

This would all be done on the server and would be fast. The problem is that the easy way to do the scaling looks bad and hits a bug in the XServer code. There is a complicated way to do it so it looks better and avoids the bug, but its complicated and I don't understand it fully yet.

So, that is why the alt-tab dialog is slow.

And when it uses XRender correctly, then we will also have live updating of window thumbnails

(In reply to comment #9)
> (In reply to comment #8)
> > Pointing out that the bug is mostly about not dealing with graphics at all.
> 
> No, the reason it is slow is 100% to do with the graphics.
> Currently to make the thumbnails the alt-tab does the following
> 
> a) Takes the backing store pixmap and turns it into a GdkPixbuf
> b) Scales the GdkPixbuf
> c) Puts it on the screen.
> 
> This requires 2 trips of copying a large amount of data between XServer and
> client. What it should do is this:
> 
> a) Take the XRender picture
> b) Apply a scale on it
> c) Draw it to the screen.
> 
> This would all be done on the server and would be fast. The problem is that the
> easy way to do the scaling looks bad and hits a bug in the XServer code. There
> is a complicated way to do it so it looks better and avoids the bug, but its
> complicated and I don't understand it fully yet.
> 
> So, that is why the alt-tab dialog is slow.
> 

Quoting the original bug reporter again:

     When doing a quick alt+tab window switching (when the user is not interested on
     seeing all the available windows, just to switch to the last-used one)

I understand this as this implies:

1. The user types alt-tab quickly, releasing alt immediately
2. The user just wants to go to the previous window
3. The user does not want to see the alt-tab dialog

Which leads means that _if_ and only _if_ the alt-tab press is short enough, we don't have to show the alt-tab dialog.

This implies: It has nothing to do with graphics. Steps a,b,c are not needed, 100% performance increase for this specific use case.

How many times a day do you press alt-tab to see the window browser? Mostly I do it quickly once to get the previous window.

That said, improving the alt-tag dialog performance if of course wanted but it is not the intention of this bug as I see it.

I was just about to report the same bug.

I agree with those that say there are two use-cases for alt-tab. 1. To very quickly switch to the previous window, often used to switch between two windows repeatedly when working. 2. To browse through all open windows in order to find something.

All of the compositor features for alt-tab -- window previews, highlighting the currently selected window, in fact even showing the alt-tab window list at all, are only useful for use-case 2, in use-case 1 they get in the way.

Currently the slowness of the alt-tab with compositing is a big problem for use-case 1 in both metacity and compiz. As someone suggested, the simplest fix might be waiting a brief moment before executing the various compositing stuff such as getting window previews, showing the window list and doing that shadow-highlight of the selected window.

But if people want to generally speed up the compositor's alt-tab behaviour when loading the previews etc. anyway, that would obviously be great.

The metacity compositor is a godsend right now because compiz is so broken usabiltiy wise. Just try alt-tab in compiz, either use case, and see what I mean. It's been shipping like that in ubuntu by default for months! So it is really great to see such attention to detail being given to the metacity compositors behaviour. Faster alt-tab would be great!

I feel it is important that adding a compositor does not create any usability regressions, as unfortunately all of them do right now.

Experiencing the slowness on a GMA3100 with fairly recent (rawhide) X and relating closely with the last two comments.
Don't really need to see the thumbnails, just switch.

I think the real fix would be to disable thumbnailing of windows. It's really confusing in compiz. My claim is that it doesn't help, it makes navigating windows harder.
Even icons (in gnome) doesn't thumbnail bigger icons to small ones, instead we have a different special cased icon for different sizes. Lets take a hint from artists ;).

A good feature would be showing the 64x64 (largest we currently have?) icon instead of the currently quite small icon. 

The only problem is distinguishing between programs with multiple windows and therefore the one or more occurrence of the same icon. But that's already present in metacity with no compositor.

Sorry for the disscussion style in bugzilla and/or minor offtopic

FWIW, this is actually the only thing I dislike about Metacity's compositor (the slow startup of alt-tab, not the alt-tab box itself).  I think comment 11 sounds like a plan: don't start drawing the box until the keys have been held down for, say, a quarter of a second.  Iain, do you think that's a workable option?  I could try doing it if you do, unless you want to.

(In reply to comment #12)
> The metacity compositor is a godsend right now because compiz is so broken
> usabiltiy wise. Just try alt-tab in compiz, either use case, and see what I
> mean. It's been shipping like that in ubuntu by default for months! So it is
> really great to see such attention to detail being given to the metacity
> compositors behaviour. Faster alt-tab would be great!

You should try the staticswitcher plugin (which should be shipped by default in Ubuntu at least since Hardy, if not Gutsy). It has an option to configure the delay for showing the popup box, just like suggested in comment #11 (but implemented before ;) ). Personally, a delay of 250ms suits me best.

(and BTW, compiz doesn't suffer from the same thumbnailing delay as metacity's compositor, because scaling window pixmaps in compiz just involves a glScale(), no expensive operations).

(In reply to comment #16)
> (and BTW, compiz doesn't suffer from the same thumbnailing delay as metacity's
> compositor, because scaling window pixmaps in compiz just involves a glScale(),
> no expensive operations).

Yes, comparing Metacity's performance and Compiz's performance is like comparing apples and frogs. Completely meaningless.

> 
> This would all be done on the server and would be fast. The problem is that the
> easy way to do the scaling looks bad and hits a bug in the XServer code. There
> is a complicated way to do it so it looks better and avoids the bug, but its
> complicated and I don't understand it fully yet.
> 

Would you mind explaining what this complicated way involves?

This bug in the XServer code you mentioned, it's not something which is likely to ever get fixed?

as a user, I'd say +1 for not showing the window switcher dialog if the alt-tab combo was not held down >250ms or so.

At the same time, I'd stress the idea of displaying bigger icons (maybe scalable ones depending on the screen width, even?) and showing bigger text sizes; but I guess this is not what this bug report is specifically about (raw performance and/or perceived performance). Are there already bug reports for those other usability issues in the switcher?

Figured it had been a while since I hacked on this bug, so I started playing with some test code last night.  Nothing special, just basically checking if a screen had a selected item in tab_popup in paint_all.  If it did and it matched cw then store that window.  Then do an Xrender transform on the image to shrink it and composite it onto the top of the stack.  This seems to work allright, and gives me live previewing, of course of just 1 window.  Do we have a bug number for the XRender bug that is preventing live previews?  I may not be noticing the bug, or maybe not triggering it.

Thanks,
Jon

I have no idea if there is a bug report
The issue was that when scaling the picture, the XServer was adding an offset and cropping the image incorrectly

This is Eric Anholts comments on the issue
< anholt> iain: yeah, I'm seeing the source being clipped to the pixmap rather
          than the window that was chosen.
< anholt> oh, yeah, there's kind of a big XXX in source clipping handling
          saying "basically this isn't implemented because nobody's needed it
          yet"
< anholt> for the untransformed case it's handled, but for transforming you
          need to hit-test each source texel through the clipping.
< anholt> to allow hardware to do this we can probably just make a temporary,
          clear it, then copyarea our source pixmap's cliprects into it, and
          use it as the source.
< anholt> the software paths would prefer that as well.
< anholt> so, the nasty hack for window thumbnailing including on unfixed
          servers (i.e. all of them today) would be to copy your chosen window
          to a temporary the size of its bounds, then do the series of 2x2
          downfilterings, then also yell at us for making your life so hard.

From the sound of your hack it does not sound like it is the correct way to go about doing it. I had something that worked once, but it was messy, looked ugly (due to the bad scaling) and required a lot of changes to the way Metacity's alt-tab window code was structured, so I left it alone. To get this working, you really shouldn't need to touch anything in the compositor code.

now I know what to look for thanks.  The scaling I was seeing was about on par with what compiz produces.  Not the best, but reasonable, of course switching it to a BiLinear filter.  

What is interesting is then I started to think.  Why scale at all?  When compositing why don't we just dump the alt+tab outline and instead make all the other windows mostly transparent and make the alt+tabbed window opaque?  I am not sure what to do about displaying multiple workspaces, but it is a work in progress.

The reason I am doing this in the compositing code is because I only want to change what is drawn on the screen.  I don't want to change the window stack yet.  I figured the best place to do this was at the top level.

Probably while this bug is still in progress it will be nice to add option to use classic windows switcher with composite? Its nice to have composite on, but current switcher is very slow.

Affects ubuntu via: http://bugs.launchpad.net/ubuntu/+bug/299330

Anyone making any progress on this bug? If not, then could we please have an off button for the previews? I'd rather have the simple version rather than a slow fancy one.

This bug still exists in Metacity 2.30: after hitting alt+tab, the dialog takes several seconds to come up for me.  This renders alt+tab completely unusable, as its only purpose is to save time.  My information:

Hardware: ATI Radeon X1600 Pro (256 MB)
Distribution: Ubuntu 10.04 (beta; fully updated as of fifteen minutes ago)
GNOME & Metacity: v2.30

Created attachment 160297 [details] [review]
disable-composited-alt-tab.patch

Here's a quick patch to use the non-compositing behaviour just for the alt-tab dialog.  Tested on Fedora 13.

(I can't believe I lived with this bug for so long when work-around is so simple!)

(In reply to comment #28)
> Created an attachment (id=160297) [details] [review]
> disable-composited-alt-tab.patch
> 
> Here's a quick patch to use the non-compositing behaviour just for the alt-tab
> dialog.  Tested on Fedora 13.
> 
> (I can't believe I lived with this bug for so long when work-around is so
> simple!)


I tried that patch on Ubuntu 9.10, using metacity 2.30.1, and it failed:
$ sudo patch -p1 < disable-composited-alt-tab.patch
patching file screen.c
Hunk #1 FAILED at 1281.
1 out of 1 hunk FAILED -- saving rejects to file screen.c.rej

I altered the patch file to be for 2.30.1, not 2.30.0, but no change. This is my first time trying to use patches, however, so it could definitely be user error.

I've noticed that my patch in Comment #28 doesn't completely fix the issue.  Its much better but on a desktop with a dozen windows open there is still a noticeable delay.  Something else slow in there other than the window contents interpolation?

Created attachment 163644 [details] [review]
disable-composited-alt-tab2.patch

Ok this also makes it slow:

win_pixbuf = get_window_pixbuf (window, &width, &height);

So I disabled that (had to delete the function to get metacity to compile because warnings=errors).  But now composited alt-tab is just as fast as non-composited.  Tested with about 30 windows open.

(In reply to comment #31)
> Created an attachment (id=163644) [details] [review]
> disable-composited-alt-tab2.patch
> 
> Ok this also makes it slow:
> 
> win_pixbuf = get_window_pixbuf (window, &width, &height);
> 
> So I disabled that (had to delete the function to get metacity to compile
> because warnings=errors).  But now composited alt-tab is just as fast as
> non-composited.  Tested with about 30 windows open.

This patch is a godsend, and it's a shame it's taken almost three years for someone to step up and fix a workaround... This issue has been the one thing keeping me from using GNOME/metacity over kwin/xfwm4 since ... ever. It's _extremely_ annoying to have to wait a given time before alt+tab switches windows, even if you let go of the keys instantly.

Many, many thanks to Colin Macdonald for issuing a workaround. I really do hope it gets commited.

Bug is opened since 2007-12-20. I opened similar bug even little bit earlier. 

I agree with Mads, its really a shame, that its impossible to use metacity as compositor because of a such a bug. Some parts of gnome really needs more love because for now metacity is kinda stalled in development for a couple years.

Is there not a way to turn of the applet? I have to wait until the thumbnails are displayed before I see the old-style border indicating the current window under alt-tab. That old pre-compositing behaviour of drawing this border is fine for me to switch open windows. I do not like to turn of compositing much, have been trying out docky..

The Ubuntu bug tracker contains a comment with a one line patch which works around this problem, it simply skips the thumbnail generation and consequently displays only the icons (the same behaviour as it would have with compositing disabled) :

https://bugs.launchpad.net/ubuntu/+bug/299330/comments/46

This bug is marked as depending on bug567757, but instead of waiting with a broken Metacity until that bug is fixed, we should just disable thumbnail generation, falling back to displaying only the icons on alt-tab.

That also have the advantage of been the most consistent behavior as it is what happens when compositing is disabled.

Guys, I recently got a rant of a user who read this bug as if the developers did not care about users. This is not the case: there has simply been *not any metacity maintainer* for the past 3y. If nobody wants to work on metacity, well nothing will be done, that's how FOSS works.

Anyway, I've hacked up a better patch around the issue (by removing the thumbnail and using larger icons like mutter), and a proof-of-concept one using cairo to maintain functionality but with terrible downscaling.

I'll try to find somebody to review the first one.

Created attachment 231653 [details] [review]
screen: Replace alt-tab thumbnails by bigger icons

gdk_pixbuf_scale_simple generates very nice thumbnails at the expense of
a very slow rendering. So slow that the alt-tab popup is not usable: it
needs 3.6 seconds to downscale 30 windows of dimension 1600x900 on an
fairly recent computer.

We remove the thumbnailing and switch to mutter-like higher resolution
icons, to be able to distinct them better, as more and more
applications are providing high res icons and it makes alt-tab blazing
fast again.

The higher resolution icons patch is only backported from mutter where
it was written by Jasper St. Pierre.

Created attachment 231654 [details] [review]
screen: Switch to cairo for scaling

Proof-of-concept scaling using cairo. This is really fast (x38 faster)
but the result is terrible because cairo is not really good at that ATM.

*** Bug 577319 has been marked as a duplicate of this bug. ***

Review of attachment 231654 [details] [review]:

generally speaking, metacity is unmaintained, and the old compositor code is not touched any more.

::: src/core/screen.c
@@ +1262,3 @@
+
+  surface_depth = cairo_xlib_surface_get_depth (scaled_surface);
+  pixmap = gdk_pixmap_new(NULL, *width, *height, surface_depth);

this is a bit odd: the cairo surface is already a pixmap; you should be able to get the XID and create a GdkPixbuf out of it.

there's the whole issue of using an intermediate Pixbuf, instead of just using Cairo to blend the Pixmaps - which is what Iain was outlining in comment 22.

Comment on attachment 231654 [details] [review]
screen: Switch to cairo for scaling

It's just a POC, it would be better to go with Iain suggestion of course.

ebassi: the second one was not meant for review. It was just an example I wanted to push the first one.

Review of attachment 231653 [details] [review]:

> The higher resolution icons patch is only backported from mutter where
> it was written by Jasper St. Pierre.

Please leave that part separate and keep the original attribution.

Replacing unique thumbnails with repeated icons is a step back in usability in my opinion, but since we removed the last dependency on metacity in gnome 3 a while ago, I don't really care about metacity anymore and the code looks fine (other than the mangling of two patches) ...

Created attachment 231801 [details] [review]
screen: Remove alt-tab thumbnails

gdk_pixbuf_scale_simple generates very nice thumbnails at the expense of
a very slow rendering. So slow that the alt-tab popup is not usable: it
needs 3.6 seconds to downscale 30 windows of dimension 1600x900 on an
fairly recent computer.

We remove the thumbnailing to makes alt-tab blazing fast again in the
composited mode.

Created attachment 231802 [details] [review]
screen: Increase typical alt-tab icon size to 96

Now we removed thumbnailing in the alt-tab switcher, the switcher is
more difficult to use with its small icons.

We switch to mutter-like higher resolution icons to be able to distinct
them better (the new size is about the same order as the thumbnails),
as more and more applications are providing high-res icons.

This patch is ported from mutter, cf
https://bugzilla.gnome.org/show_bug.cgi?id=689651

Review of attachment 231802 [details] [review]:

I would've expected this patch to go first, but sure ...

Review of attachment 231801 [details] [review]:

Code looks good

Attachment 231801 [details] pushed as 04ad173 - screen: Remove alt-tab thumbnails
Attachment 231802 [details] pushed as 861d49c - screen: Increase typical alt-tab icon size to 96