Hi folks, I must admit that I for now gave up on trying to make the decoration module more efficient. I tried two of the three ideas I had, and they didn't work well at all. My third idea (turning most of the lists in the decoration module into binary trees) is likely to work well, but for now I don't have time to implement it, particularly because it's not one of my main issues I would like to see addressed in xmonad. Related to the above, however, I noticed that even without decoration, fast focus switches drive my CPU usage up, much more so than in other non-tiling window managers. Running top gave me a surprising insight: it's not xmonad but the X server that consumes that many cpu cycles when focus switching. Here's my theory of the source of the issue: every focus change triggers the recomputation of the layout (as it should because some layouts rearrange windows in response to focus changes), and every recomputation of the layout updates the geometry of every window currently visible - that's a lot of work on the X server's side for a simple focus change. (1) Can anybody who is more familiar with the inner workings of xmonad core confirm that this is indeed what's going on? (2) A fairly simple fix for the above would be to cache the geometries of visible windows and tell the X server to update a window only if its geometry has in fact changed. Does anyone on the list have a feel for how hard it would be to add such a caching mechanism to xmonad core? Would it break anything? At this point, I'm simply pondering what can be done about it, as one of the reason's I'm using xmonad is that I want a lightweight desktop environment. (When fast focus changes drive one of my cores to 50%, that's hardly lightweight.) It'll be a while before I would get around to trying to implement the above. Cheers, Norbert -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments