Changing a window title quickly with ewmh enabled makes xmonad unresponsive

[l29ah]

Problem Description

When i use an app that can change window titles quickly (say, paludis or tkabber), xmonad doesn't respond for a while after such events, burning cpu cycles.

Configuration File

I use urxvt and for nvm in $(seq 0 1000); do echo -e '\e]2;test\a'; done to reproduce it. On my config (https://github.com/l29ah/xmonad-config) this makes xmonad unresponsive for the next 30 seconds or so, with the minimal test config the time is about 5s (yet if i drop ewmh from mine it doesn't slow xmonad at all).

module Main (main) where

import XMonad
import XMonad.Hooks.EwmhDesktops

main = xmonad $ ewmh defaultConfig

Checklist

• I've read CONTRIBUTING.md

• I tested my configuration with xmonad-testing

[l29ah]

It occurs in ewmhDesktopsLogHook.

[bgamari]

I have also long noticed that xmonad and taffybar are together rather absurdly sluggish and CPU-hungry. Today was a warm summer day where I wanted to work with my laptop on my lap and so after three years of tolerating this situation I decided I would finally investigate.

As pointed out above, the EWMH log hook is extremely naive. Every time ewmhDesktopsLogHook is invoked it updates all of the major EWMH properties, regardless of whether their values have actually changed. This in turn causes Taffybar to do a complete rebuild of its interface. As far as I can tell this all keeps a CPU occupied for tens to perhaps one hundred milliseconds. This appears to happen several times per second (judging by the output of xprop -root -spy).

This is just silly.

I'm no X11 expert but I suspect just adding a bit of caching to verify that something has actually changed before sending the property updates would alleviate a significant fraction of this busywork.

Determining why we are doing this several times per second would also be interesting. However, the caching is the easier place to start.

[geekosaur]

The logHook is run on focus or workspace changes, and probably titlebar / app WM_NAME changes. If something is doing any of those that often. it's a bit pathological. (An argument could be made for the WM_NAME changes, but it's not a very strong argument.)

[bgamari]

Pathological or not, I have been observing this behavior in my environment for years. It's not clear what causes the events, but I see no reason why the window manager should wake-up clients claiming properties have changed if there has been no change in value.