[xmonad] Delays in focus update...

[Norbert Zeh]

Norbert Zeh [2012.02.07 1657 -0400]:
> Norbert Zeh [2012.02.07 1646 -0400]:
> > Allen S. Rout [2012.02.07 1512 -0500]:
> > > On 02/06/2012 05:31 PM, Norbert Zeh wrote:
> > > 
> > > >I did a very superficial test of the source of the problem, and in my case it
> > > >seems to be the decoration module that adds tabs above all my windows.  Without
> > > >decoration, I can open 30+ terminals and focus switch feels almost snappy and
> > > >certainly does not trigger the endless loop.  The moment I turn any form of
> > > >decoration on, focus switching, at least with many windows, starts to feel
> > > >sluggish.  Are you using window decorations?
> > > 
> > > I don't think so;  I've attached my current xmonad.hs, Just In Case
> > > I'm too dumb to know that I'm decorating them.   Visually, I've just
> > > got the little red borders, of width 1.
> > 
> > Indeed, your config doesn't look like your using anything decoration-related.
> > The part that confuses me in this case about the poor performance you are
> > observing is that, once I remove decoration from my windows, I didn't notice any
> > substantial delays in focus update.  Admittedly, I tested only with at most 10
> > windows per screen, I think.  When (and if) I get a chance, I will try without
> > decoration and tons of windows once more, and I may give your configuration a
> > spin.
> 
> Testing your config may take a little longer, but I thought it's easy and quick
> to test my own setup without decoration.  I'll test on 4 monitors with 30
> windows per screen once I get home.  For now, on my laptop, I quickly fired up
> 30 windows on the one screen it has.  What I observed was that focus switches
> felt really snappy.  The one caveat I observed was that the delay from dealing
> with a larger stack, while not really noticeable as such, was apparently enough
> to trigger the race condition in pointer updates using UpdatePointer, so that
> again I ended up in an endless loop of focus switches between two or three
> windows.
> 
> Given that, even on my laptop and with as few as 10 windows (well, 10 windows is
> not really "few", but there are situations where I do actually tile 10+ windows
> in a grid layout, at any point in time maximizing the one I'm working on), I see
> a distinct an serious slow-down in focus switching once I turn on decoration,
> the biggest culprit to me certainly seems to be the decoration module...so I
> will continue my quest to rewrite the decoration code.  Let's see how much
> progress I'll make tonight.

Alright.  Tested with 4 monitors, 30 windows per monitor, no decoration.
Indeed, there is a lag in focus switching, but it is not unbearable.  Then again
I haven't used KDE in over a decade...does KDE really manage to switch windows
instantly once you load it with 120 windows?  It's possible because managing
windows using a zipper...in Haskell...well, there is some overhead to be
expected when compared to optimized imperative C/C++ code.  I think for most
people, this whole thing is a non-issue, though, as most of us, most of the time
don't work with 100+ windows at a time ;)

On a related note: I turned decoration back on before killing the 120 windows I
had created for the above test.....had to kill the X server after my processor
spun at 100% for about a minute ;)

So, on to continuing the quest for more efficient decoration code.

Cheers,
Norbert