Multiple monitors - eg four - are common in financial market work, where keeping lots of customized data tiled on screen, at all times, can have a significant productivity advantage. Screen real estate is valuable! It's also nice for devs who keep lots of scripts and tools monitoring their work. On Monday, February 6, 2012, Philipp Haselwarter wrote:

completely skipping on your question, but you just got me curious -- what kind of task do you work on that allows/requires you to use four monitors? I just upgraded to two, giving me 3840x1200 which is really comfortable for having Emacs on one screen and firefox or whatever else on the other, but that's about as much as I can deal with at one time. just made me wonder =)

-- Philipp Haselwarter

_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

On 02/06/2012 05:21 PM, Philipp Haselwarter wrote:

completely skipping on your question, but you just got me curious -- what kind of task do you work on that allows/requires you to use four monitors?

Heh! Well, I'm GLAD YOU ASKED. :) Gives me an opportunity to expound on my WM history and thinking. --- What I'm doing now. All my screens are set up portrait. My leftmost screen usually holds email or IM panels. My rightmost screen usually holds a web browser. My two center screens hold whatever project I'm working on, and I tend to think of the project screens in pairs. So right this instant, my left-center screen is an org-mode emacs buffer with a data-collection status report I just updated. I've also got two shells in it, mostly squooshed to the bottom, with an R session that helps me develop the analytics that go in the report, and a random shell in that report directory so I can e.g. run data-collection sripts. The right-center is full-screen of an evince window, which is displaying the output of the most recent build of the report. Here's a picture, if anyone cares. http://muntok.routhouse.org/pictures/misc/ These days I'm optimizing by identifying visual work patterns, and making it easier to set them up quickly. So I've got a keystroke bound to "basic TSM monitoring" (I manage some backup infrastructure) and one to "Document project 1", etc. , ((modm .|. shiftMask, xK_s ), do { windows (viewOnScreen 0 "tsmmon" )

...

windows (viewOnScreen 1 "tsmsess" ) } )

, ((modm .|. controlMask, xK_1 ), do { windows (viewOnScreen 0 "doc1e" )

...

windows (viewOnScreen 1 "doc1d" ) } )

and 25 workspaces at the moment. Added four last week. :) My eventual goal is to roll up the variety of display patterns I've defined, and express them in a data structure. Once that's done, I can gridSelect any of them, and reserve the keystrokes for the really common ones. --- History I've been fiddling with X since the late 80s, and have messed with a variety of virtual-desktop memes; I used twm, vtwm, tvtwm and eventually settled on ctwm. Before ctwm, all of the virtual desktop schemes had some or another geometric idiom behind them. Windows were placed either according to a big root desktop you scrolled around on, or relative to your viewport. CTWM, on the other hand had 'workspaces', which are mostly analogous to xmonad workspaces, though different in detail and implementation. You named a family of workspaces, and then had 'occupation' directives which told you which X clients would be mapped when which workspaces were active. For years, I was happy with three X screens (e.g. .0, .1, .2). The one on the left was my 'commo' screen, and had (on different workspaces) various mail interfaces and IM clients. The one on the right was my 'web' screen, and had a variety of browsers (on different workspaces). In the center I had two TwinView-joined screens, as .0, and that was where my projects lived. I had 20 workspaces defined at the time I left that config. I actually peaked at 6 displays: I put our monitoring system on one of them, but couldn't figure out a rational use for screen 6. A co-worker suggested that, since it occluded my window, I could put a webcam out the window and display that as screen 6. :P If I were doing it again, screen 6 would be for my 'remote desktop' uses. - Allen S. Rout

On Mon, Feb 6, 2012 at 5: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 am not entirely certain what inside the decoration module would create such massive delays - the CPU usage on one of my cores goes up to 50% when I'm in the endless loop.  I'm not too keen to dig into it because this module is a monster, but it may simply be necessary.

Why does this issue - 'Tabs is horrible for performance!' - sound so very similar... Perhaps it's time to add a warning to the Tabs haddocks to the effect it is known to hurt performance. -- gwern http://www.gwern.net

Brandon Allbery [2012.02.06 1744 -0500]:

On Mon, Feb 6, 2012 at 17:31, Norbert Zeh wrote:

Allen S. Rout [2012.02.06 1453 -0500]: > But I've noticed a certain lack of responsiveness when I make > sweeping motions with the mouse, and I've now done a bit of an > experiment  that seems to narrow it down.

I am not entirely certain what inside the decoration module would create such massive delays - the CPU usage on one of my cores goes up to 50% when I'm in the endless loop.  I'm not too keen to dig into it because this module is a monster, but it may simply be necessary.

Two things that come to mind are that

(a) decoration windows are, somewhat uselessly, part of the StackSet and must be traversed whenever the StackSet is searched for the newly focused window;

I had one brief look at the decoration code and decided that I do not want to understand it. Maybe it's time to reevaluate this decision. Making these windows part of the stackset is certainly completely wrong. It's equivalent to having the frame X window of a reparenting window manager show up in the window list. However, adding them to the stack should only cause a factor 2 slowdown, while the slowdown I experience is more a factor 10+.

(b) Decoration registers interest in all events on decoration windows, specifically including mouse events IIRC, and (usually pointlessly) invokes a (usually stub) handler on such events.

This sounds more like the real culprit.

BTW, the tabs module really needs to be rewritten not to use Decoration; not only is Decoration inefficient, as above, but tabs are actually a rather poor fit for Decoration because most of the Decoration code assumes decoration windows take up space near the real window, and odd things happen with respect to space allocation when they are instead located somewhere else.  (I have local hacks around that which fix most of the odd things with respect to figuring out the available workspace area, but not all of them; and it still leaves the performance issues.)

I am actually using decoration to add "title bars" above my windows. So, while separating the decoration and tab modules may be a good idea due to the reasons you cite, it wouldn't help fix the performance issues for people (like myself) who actually do use decoration as it was meant to be used. Bottom line: someone will have to look at that decoration code, maybe I when I find the time, but I'd be happy if someone else beat me to it ;) Cheers, Norbert -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

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. - Allen S. Rout

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. Cheers, Norbert

On 02/07/2012 06:27 PM, Norbert Zeh wrote:

Norbert Zeh [2012.02.07 1657 -0400]:

Alright. Tested with 4 monitors, 30 windows per monitor, no decoration. Indeed, there is a lag in focus switching, but it is not unbearable. [...]

So I don't want to go down a blind alley here: I'm not suggesting that 30 terminals, each 2 characters wide, is a rational work environment. :) My tossing 20-30 terminals on a screen was a way to exacerbate the problem so it was easy to measure. The Real Problem is that I can sweep my mouse pointer across my desktop, to (for instance) move from the web browser to an editor, start typing, and get my input lost. I haven't yet gotten bits distributed over other windows, but I fear that. Some semi-random set of keystrokes accidentally dropped in an interstitial root window. *shudder*. The most common case of this is when I copy something to the cut buffer, and go 'somewhere else' to paste it. At the moment, I've added to my mental process a "pause and wait for the G- D- border to turn red". Otherwise things get pasted into nowhere. That's a serious interruption of flow. - Allen S. Rout

On 02/08/2012 11:21 AM, Norbert Zeh wrote:

Allen S. Rout [2012.02.08 0921 -0500]:

...

The most common case of this is when I copy something to the cut buffer, and go 'somewhere else' to paste it. At the moment, I've added to my mental process a "pause and wait for the G- D- border to turn red". Otherwise things get pasted into nowhere. That's a serious interruption of flow.

How long a focus delay are we talking about? When I tested, even with the excessive number of 30 windows per workspace, the focus moved between windows faster than I would have been able to move my hand back from the mouse to the keyboard. So either you are extremely fast at sweeping across with your mouse and then starting to type or there is something else in your setup which makes the delay more serious than I was able to observe.

Well, Copying a phrase from 'A' and then pasting it on B (on the other side of my screen layout) the delay approaches zero. A tenth of a second is noticable, a third of a second is irritating. I seem to be getting results which are seldom more than a second, but frequently more than half a second. Here is a snippet of xev output from my sweeping the mouse across the screen. Incidentally, I was going to paste something in my editor window when I recorded this, and missed. :) PropertyNotify event, serial 24, synthetic NO, window 0x8400001, atom 0x143 (WM_STATE), time 2950262434, state PropertyNewValue PropertyNotify event, serial 24, synthetic NO, window 0x8400001, atom 0x143 (WM_STATE), time 2950262548, state PropertyNewValue PropertyNotify event, serial 24, synthetic NO, window 0x8400001, atom 0x143 (WM_STATE), time 2950262654, state PropertyNewValue PropertyNotify event, serial 24, synthetic NO, window 0x8400001, atom 0x143 (WM_STATE), time 2950262766, state PropertyNewValue PropertyNotify event, serial 24, synthetic NO, window 0x8400001, atom 0x143 (WM_STATE), time 2950262876, state PropertyNewValue PropertyNotify event, serial 24, synthetic NO, window 0x8400001, atom 0x143 (WM_STATE), time 2950271084, state PropertyNewValue - Allen S. Rout