Gwern Branwen [2012.02.12 1818 -0500]:

On Sun, Feb 12, 2012 at 4:54 PM, Norbert Zeh wrote:

...

The reason why I'm writing about this *before* putting the effort into testing all my changes is that I'd like to know how the community feels about a change in the interface of the DecorationStyle type class.  As it is, there are only two choices: accept this change or continue to live with quadratic-time behaviour of all or at least most decoration modules because the latter is unavoidable with the current interface.  This change in interface should only affect other modules in XMonadContrib, and I've converted them to the new interface already.  User configurations should not be affected even for the majority of people who use window decorations because they will normally simply use the layout modifiers based on the decoration module - they will not directly use the DecorationStyle class.

/puts on XMC commit hat

The performance issue is a serious one, which has caused emails for years now, and has no doubt irritated many users. I'd rank it as one of the most serious issues with stock XMC and something that should. If the performance really is fixed by a breaking API change, then I'm cool with it as long as the 8 or 9 modules using DecorationStyle are also fixed - breaking the compile or runtime is pretty non-negotiable.

Of course! So I'll coninue working on this. I just finished a test with NoFrillsDeco based on the new Decoration module. It's faster but not fast. I'll have to put this on the backburner for a few days...conference deadline. After that I'll have to think a little harder how to see how to cut down on CPU cycles even more. As an indication of what "faster" means: Before, 30 windows per workspace led to delays of several seconds in layout updates on my machine. Now I have this down to probably about half a second. With 15-30 windows on a workspace, things feel quite a bit snappier but still sluggish compared to not having decorations at all. It gets really fast only once you're down to about 6-10 windows, at which point the old module is also reasonably usable. Cheers, Norbert

On Sun, 12 Feb 2012 20:18, wagnerdm@seas.upenn.edu wrote:

Quoting Gwern Branwen :

...

User-wise, I'm not concerned. There's only one config in my copy of the config archive which even imports XMonad.Layout.Decoration, and that config apparently isn't even current since it doesn't show up when I download a fresh copy*; perfectly acceptable collateral damage.

Given the amount of traffic on the list about decorations in the last few days, I'd take this as evidence that your config archive is woefully incomplete, not that decorations are unused by xmonad users.

There's another explanation: Almost no one uses Layout.Decoration directly, but rather various other modules (most notably Tabbed, I guess) that use Decoration internally but whose external interface would not change if Decoration's interface changed. Cheers, Daniel

wagnerdm@seas.upenn.edu [2012.02.12 2017 -0500]:

Quoting Norbert Zeh :

...

The reason why I'm writing about this *before* putting the effort into testing all my changes is that I'd like to know how the community feels about a change in the interface of the DecorationStyle type class. As it is, there are only

Is this interface one which is likely to be used in user configs?

That is, after you make the necessary changes to XMC code, do you think it's likely users will also have to update their configs in the same way? Or are the most public APIs the same?

Users will only be affected if they write their own instance of the DecorationStyle class and use it in their xmonad.hs. If they use any of the standard layout modifiers, such as TabBarDecoration, NoFrillsDecoration, and the likes, they won't notice any change. Alas, this is more literally true than I hoped. Upon closer comparison of the two versions of Decoration.hs, I currently see hardly any performance difference, which is odd because, at least for 30ish windows, there should be about a factor 5-6 difference in speed. I suspect that I'm doing way too many conversions back and forth between different representations of the stack and the window-rectangle mapping returned by the underlying layout. I have a number of ideas how to avoid these conversions and avoid lookups in many places, but implementing all these tweaks will take time. In any case, no matter what I end up doing with Decoration.hs, one of my top priorities is to ensure that the above remains true. After all, since I started using xmonad, part of its appeal has always been its stable API. Cheers, Norbert