Squib of the day: speed up alt-tab under compositing

Light Switch ComplicatorGNOME bug 504729 suggests that switching with alt-tab, while using compositing, is too slow. This is because all the images of the windows are scaled on the client side before the window is displayed.

There are two possible answers to this problem.

Firstly, we can check for key release while scaling is happening, and if one is received, abort scaling and simply switch to the next application.

Secondly, scaling can be faster if it’s done server-side.  This is possible but apparently there’s a common bug that it hits.  Fixing this would also mean that we got to have animated previews easily.

I think the first solution should be added in any case, and the second should be added when it’s possible.  I can add the first solution; I’m not sure I know enough to fix the second.

Photo © L. Marie, cc-by.

Published by

Thomas Thurman

Mostly themes, triaging, and patch review.

2 thoughts on “Squib of the day: speed up alt-tab under compositing”

  1. On my MacBook here, I have to hold down Alt-Tab for about half a second (guesstimate) for the switcher to appear, but if I just tap Alt-Tab and release the correct target window is focussed without the switcher appearing, so it seems that (1) is already within acceptable limits. If I hold down Alt and double-tap Tab before the switcher appears, then when it *does* appear the correct window is highlighted. However, if I press Alt, double-tap Tab and release Alt before the switcher appears, it behaves as though I’d only pressed Tab once.

    If calculating snapshots takes a while, I’d prefer the behaviour to be:
    1. User holds down Alt and taps Tab.
    2. Metacity displays switcher, showing the icon for each window.
    3. Metacity kicks off a thread (or whatever) to calculate the thumbnail for each window.
    4. As each thread completes its thumbnail, the switcher replaces the respective window icon with the thumbnail+icon we have now.
    5. When the user releases Alt, any thumbnailing threads still in progress are killed and the intended window is focussed.

    It’s not strictly necessary to kill the thumbnailing threads, I guess – I wouldn’t care if they ate CPU while I was busy typing in another window, I just don’t want to have to wait for them while I switch windows.

    If the second solution fits into the existing switcher framework, gives live thumbnails for free and makes the tab-switcher appear Fast Enough(TM), it may be worth just going for that solution and not bothering with the interim solution at all.

Leave a Reply

Your email address will not be published. Required fields are marked *

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.