headers
Allen S. Rout | 6 Feb 20:53
Picon

Delays in focus update...


I'm running xmonad now on a 4-monitor setup which is slowly approaching 
perfect-for-me.  Yay, and thanks!

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.

To observe this behavior:

+ open up a lot of shells.  Mod-shift-enter 15 or 20 times on an empty 
workspace will do.

+ Pick a side of the screen which is an edge, not adjacent to another screen

+ Move your mouse to that screen, on the -opposite- side from the edge.

+ Swiftly move your mouse to the edge,  like _fast_.  10th of a second 
or so.  You're crossing many terminals.

+ Watch the successive terminals momentarily get focus;  count the time 
(seconds if you go nuts on the count) it takes for focus to get where 
your mouse is.

.... So it seems it takes constant, substantial subsecond time between 
window X gets focus, and when xmonad is willing to consider that it 
might have lost it.

Is there some timing loop in there?  Or is there something fundamental 
and X-y happening that limits this?    In other WMs, I'm accustomed to
(Continue reading)

Permalink | Reply |
headers
Philipp Haselwarter | 6 Feb 23:21
Picon
Picon

Re: Delays in focus update...

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
Permalink | Reply |
headers
Don Stewart | 7 Feb 00:08
Picon
Gravatar

Re: Delays in focus update...

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 <philipp.haselwarter-Mmb7MZpHnFY@public.gmane.org> 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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>

Permalink | Reply |
headers
Norbert Zeh | 7 Feb 00:30
Picon
Picon
Favicon

Re: Delays in focus update...

Don Stewart [2012.02.06 1808 -0500]:
> 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.

Well, I'm actually a plain old academic and wouldn't want to miss my four
monitors any more.  It helps to be able to have a preview of the paper one is
writing one one screen (in portrait mode so a whole page is visible at a
readable zoom factor), having maybe a paper one needs to discuss in a "previous
work" section on a different portrait monitor and, in between, on the remaining
two monitors, editor, drawing program, shell, ...  It's not hard to fill four
monitors and use a workflow that would be significantly less efficient with
fewer monitors.  Then again, I of course survived quite happily with two
monitors before, and with a single 17" monitor before that.  As hardware gets
cheaper, one says, "Why not.  It makes work easier and more enjoyable."

Cheers,
Norbert

> 
> On Monday, February 6, 2012, Philipp Haselwarter <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@...
> > http://www.haskell.org/mailman/listinfo/xmonad
> >

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

--

-- 

()  ascii ribbon campaign  -  against html e-mail
/\  www.asciiribbon.org    -  against proprietary attachments
Permalink | Reply |
headers
Allen S. Rout | 7 Feb 19:23
Picon

Re: Delays in focus update...

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
Permalink | Reply |
headers
Norbert Zeh | 6 Feb 23:31
Picon
Picon
Favicon

Re: Delays in focus update...

Allen S. Rout [2012.02.06 1453 -0500]:
> 
> 
> I'm running xmonad now on a 4-monitor setup which is slowly
> approaching perfect-for-me.  Yay, and thanks!
> 
> 
> 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.
> 
> To observe this behavior:
> 
> + open up a lot of shells.  Mod-shift-enter 15 or 20 times on an
> empty workspace will do.
> 
> + Pick a side of the screen which is an edge, not adjacent to another screen
> 
> + Move your mouse to that screen, on the -opposite- side from the edge.
> 
> + Swiftly move your mouse to the edge,  like _fast_.  10th of a
> second or so.  You're crossing many terminals.
> 
> + Watch the successive terminals momentarily get focus;  count the
> time (seconds if you go nuts on the count) it takes for focus to get
> where your mouse is.
> 
> 
> .... So it seems it takes constant, substantial subsecond time
> between window X gets focus, and when xmonad is willing to consider
> that it might have lost it.
> 
> Is there some timing loop in there?  Or is there something
> fundamental and X-y happening that limits this?    In other WMs, I'm
> accustomed to focus shifting nearly instantaneously, but I might be
> missing something.

I just tested this on my 4-monitor setup.  I don't think it's the number of
monitors that makes a difference.  It's the number of windows you open.  I am
using UpdatePointer, and there the delay in focus update may in fact lead to an
infinite loop of focus switching between two windows where triggered the loop by
moving the pointer back and forth quickly between the two windows ininitially.

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.

Cheers,
Norbert
Permalink | Reply |
headers
Gwern Branwen | 6 Feb 23:40
Picon
Gravatar

Re: Delays in focus update...

On Mon, Feb 6, 2012 at 5:31 PM, Norbert Zeh <nzeh <at> cs.dal.ca> 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

_______________________________________________
xmonad mailing list
xmonad <at> haskell.org
http://www.haskell.org/mailman/listinfo/xmonad
Permalink | Reply |
headers
Brandon Allbery | 6 Feb 23:44
Picon
Gravatar

Re: Delays in focus update...

On Mon, Feb 6, 2012 at 17:31, Norbert Zeh <nzeh-RazJlWb3c/r3fQ9qLvQP4Q@public.gmane.org> 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;

(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.

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.)
 
--
brandon s allbery                                      allbery.b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

Permalink | Reply |
headers
Norbert Zeh | 7 Feb 00:24
Picon
Picon
Favicon

Re: Delays in focus update...

Brandon Allbery [2012.02.06 1744 -0500]:
> On Mon, Feb 6, 2012 at 17:31, Norbert Zeh <nzeh@...> 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
Permalink | Reply |
headers
Norbert Zeh | 7 Feb 02:23
Picon
Picon
Favicon

Re: Delays in focus update...

Norbert Zeh [2012.02.06 1924 -0400]:
> Brandon Allbery [2012.02.06 1744 -0500]:
> > On Mon, Feb 6, 2012 at 17:31, Norbert Zeh <nzeh@...> 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 ;)

Alright.  I at least *started* to look and found two sources of inefficiency,
one which I thought would be major but which is actually insignificant in
comparison to the other one, the other one really troublesome:

1) The decoration state associating windows with their decorations is a list.  I
need to check how these are used, but I remember seeing a lookup in this list
later on.  By storing this in a Map instead, we could cut the time per operation
from linear to logarithmic.

2) At least the default implementation of pureDecoration, which is used at least
by the simple decorations based on the Decoration class, checks for every window
to be decorated whether it is in the stack.  This takes *quadratic* time.  Now
I'm no longer surprised at the poor performance because every layout update on a
workspace with 8 windows now incurs a cost equivalent to walking through a stack
with 64 windows in it!  By doing these lookups more cleverly, we can at least
reduce the time to a more reasonable n log n.

Cheers,
Norbert
Permalink | Reply |
headers
Allen S. Rout | 7 Feb 21:12
Picon

Re: Delays in focus update...

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
Attachment (xmonad.hs): text/x-haskell, 13 KiB
Permalink | Reply |
headers
Norbert Zeh | 7 Feb 21:46
Picon
Picon
Favicon

Re: Delays in focus update...

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.

Cheers,
Norbert
Permalink | Reply |
headers
Norbert Zeh | 7 Feb 21:57
Picon
Picon
Favicon

Re: Delays in focus update...

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
Permalink | Reply |
headers
Norbert Zeh | 8 Feb 00:27
Picon
Picon
Favicon

Re: Delays in focus update...

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
Permalink | Reply |
headers
Allen S. Rout | 8 Feb 15:21
Picon

Re: Delays in focus update...

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
Permalink | Reply |
headers
Norbert Zeh | 8 Feb 17:21
Picon
Picon
Favicon

Re: Delays in focus update...

Allen S. Rout [2012.02.08 0921 -0500]:
> 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.

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.

Cheers,
Norbert
Permalink | Reply |
headers
Allen S. Rout | 8 Feb 19:53
Picon

Re: Delays in focus update...

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
Permalink | Reply |
headers
Allen S. Rout | 8 Feb 22:01
Picon

Re: Delays in focus update...

On 02/08/2012 09:21 AM, Allen S. Rout wrote:

>  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*.

OK, this has now happened, and yet wierder crap is happening inside of 
it.  I moved my pointer from my mail window, across a path that left one 
screen, crossed an Emacs buffer, and entered a shell.

I did this to type the command 'date'.  As you might imagine, that's an 
easy and fast one.

The 'd', 'a', and the 'e' landed on the terminal.  The 't' was inserted 
at point in the Emacs.

I've got a screenshot that shows it.

http://muntok.routhouse.org/pictures/misc/

Ick.

- Allen S. Rout
Permalink | Reply |

Gmane