Task manager window grouping failures and KWin window-action slowness

[Duncan]

Stephen Dowdy posted on Sat, 05 Aug 2017 11:23:38 -0600 as excerpted:

> I have LOTS of windows, and while task manager window grouping in KDE4
> started off pretty bad early on, it got better for me.
> 
> In Debian Jessie, i would have issues running 3 different firefox
> profiles with differing Class Instance names, where it would still
> *usually* correctly separately group them, but sometimes draw the
> incorrect icon for them.
> 
> Now, in Debian Stretch, the icon managers are *TERRIBLE* at grouping my
> firefox windows.
> 
> I have *hundreds* of firefox windows, and i'm lucky if task manager
> manages to make 1 or 2 groups of a few tens or dozens, and then ALL of
> the rest become individual task manager icons.
> 
> (race condition?)

Sounds like it.

Right here at the top I'll mention that my usage is much different than 
yours so the degree of practical help I can provide is very limited, but 
I do run live-git "kde family", from frameworks, thru plasma and apps, 
and follow plasma's (that's the whole desktop including kwin, plasma 
system settings, etc, not just the shell) development via the plasma-devel 
list which gets all the pre-master-merge discussion, and am thus at least 
somewhat aware of developments that don't directly affect my own use, but 
will affect yours.  It's on that basis that I'm replying.

I neither group windows nor use a taskbar at all, here, preferring window 
management alternatives such as the alt-tab switcher, multiple desktops 
with switching via desktop scroll or cube, the window list menu which I 
have configured to popup with a "middle" button click, etc.  It also 
helps that I have a /huge/ desktop, a 65"/165cm 4K TV (3840x2160) as my 
primary monitor, with window rules set to default most windows to 
1280x1080, so I can do a 6-off grid of three windows wide by two high, so 
I don't need to Z-axis stack them so deeply, particularly when using 
multiple desktops as well.  (I also have a secondary 48"/122cm "full-HD" 
TV (1920x1080), on which I can and often do have a full-screen youtube or 
the like session playing, the idea being it can be full-screen on that 
monitor and still not encroach on my 3x2-window main work display area.)

Between that and the fact that I'm an old-timer whose computer workflow 
consists of opening windows to work on, working on them, then closing 
them, closing and restarting windows/apps as needed rather than leaving 
them hanging around unused for days at a time, I don't usually get the 
number of windows you're quoting and thus don't tend to end up /needing/ 
to manage hundreds of windows at a time.

Tho I will often open up to perhaps 50 firefox windows or so while 
catching up on news, along with a news/feed/mail reader (which close to 
the tray and I seldom have more than one open at a time), maybe a reply 
window for messages such as this, and perhaps 2-3 konsole windows if I'm 
updating (gentoo so that means building from sources) the system at the 
same time.

But still almost never more than 100 windows, and most of the time under 
50, quite a way from your several hundred.  But it works for me, and if 
yours works for you... =:^)

> I prefer using Icon-only Task Manager with "Show Launcher when not
> running"  (though, interestingly, in Icon-only mode, there's not "Group
> Windows" setting button)
> 
> I have tried switching "Alternatives" hoping that doing so would issue a
> "regroup" operation, but it seems that the grouping algorithm is done
> one-time at window creation in some common code?

I'd expect so... people don't tend to like windows showing up in one 
group, then moving to a different one just because the name of the window 
changed or something similar, after all.

> Is there any way to FORCE the code to re-evaluate grouping?  Or, is this
> bug fixed in subsequent Plasma or KDE Frameworks (or whatever component)
> releases?

One "hackish/manual" technique I've had some success with, is using the 
command line at first, then scripting if whatever bug is forcing it 
continues to happen frequently enough, to quit (kquitapp or killall, or 
using htop, ksysguard, etc) and restart whatever plasma component, 
whether that be kwin (kwin-x11), plasmashell (the desktop activities and 
panels themselves), krunner (the run dialog), xembedsniproxy (the 
"legacy" tray app proxy), etc.  Just don't try to quit and restart 
ksmserver, startx, xinit, startkde, etc, or you'll shutdown the entire 
session!

In fact, I've one entire hotkey launcher menu dedicated to resetting/
restarting various components, both kde/plasma related as above, and 
otherwise (resetting mouse accel (xset m(ouse)), keyboard repeat rate 
(xset r(epeat)), reloading my now kde-independent due to kde breaking 
what was working just fine with no work-alike alternative on major 
upgrades several times hotkey app (sxhkd for the hotkeys and a hand-
rolled konsole/bash-script combo for hotkey menus) after editing its 
config, etc).

Since I don't use window grouping I'm not sure which component handles 
that, but I'd guess restarting either kwin or plasmashell (and thus 
whatever taskbar-ish you're using), depending on what handles the 
grouping, would do it.  As I said I have both of them listed in my resets 
hotkey menu, here.

> Additionally, i like to set window-action for double-click title bar to
> "lower".  with many windows, it can sometimes take 30 seconds for the
> action to complete.  it sits there doing nothing, and i don't know for
> sure if it's that i keep hammering at it, or i move the mouse and click
> in different windows, then hammer on it some more, but it eventually
> will do a lower. (it's not ALWAYS that slow).  Sounds to me like some
> code branch goes off to evaluate something and gets all caught up in
> some operations that don't scale very well to hundreds/thousands of
> windows).

As mentioned I run live-git kde-(frameworks/plasma/apps) here, and follow 
plasma development.  They've been working on the grouping code fairly 
recently, adjusting the matching for firefox and chrome/chromium windows 
for sure.  IIRC they were using regex (I believe it was regex, not shell-
wildcards, but please verify before depending on that), I believe via qt's 
regex services, for matching the groups, and tweaked the regexes to 
account for recent changes, etc.

I've no idea how to get what current live-git frameworks considers its 
version number (update, frameworks 5.37.0 according to konsole's about 
konsole, libraries tab), but for reference, plasmashell --version reports 
5.10.90 (which I believe is pre-release for 5.11), here, compared to your 
5.8.6, below.

Google says plasma 5.8.6 was released on February 21, 2017, so it's not 
that old, but the 5.8 series is of course an LTS, with 5.8.0 released on 
Oct 4, 2016, again according to google.  Tho of course they'd have 
branched what was to be the 5.8 LTS some time before that.

So you do very likely have the window-grouping code changes still ahead, 
unless they backported them before the 5.8.6 release in February.

Meanwhile, I can see the lower possibly taking awhile on hundreds of 
windows, particularly if they haven't optimized window trees for fast 
access with hundreds or thousands of windows in mind, **ESPECIALLY** if 
it means they have to go searching the perhaps unordered window list 
multiple times to match all the grouped windows so they don't lose track 
of Z-stack order for the group, with some still set as somewhere other 
than bottom of the Z-stack.

Meanwhile, if I may ask, how many core and hyperthread is your CPU?  What 
does CPU usage do during this 30 seconds?  Does it spike on one core/
thread, all of them, or no significant increase?  With hundreds to 
thousands of windows, particularly if it's unoptimized as my suggestion 
above, if the code isn't multi-threaded, I can certainly see it taking 
some time.  Multi-threaded would help with that, but of course 
dramatically increase the possibility of race conditions at least in 
relatively early code, until the bugs are worked out.  And with few 
people likely having that many windows (I've seen people report hundreds 
of firefox /tabs/ before, but not hundreds of windows), it could be 
awhile before all the race conditions are reported, traced, and fixed.

And memory.  How much and do you run swap, and how far into swap do you 
go, if you do?  Of course if some of these windows are swapped out and 
have to be swapped in to manage (not that they do, but if...)...

FWIW, 6-core AMD bulldozer-1 (fx6100) here, overclocked to 3.7 or 4.07 
GHz (3.7 previously reported, 4.07 reported on kernel 4.13-rc3, don't 
know yet if it's a fix or regression in 4.13, but IIRC the slightly above 
4 better agrees with the bios overclocking page so it /might/ be a fix, 
tho I've not rebooted to the BIOS since discovering it to verify what it 
says there so that's from memory).

16 GiB RAM, no swap and swap disabled in the kernel config too.  
Typically I use a quarter to a half of that, 4-8 GiB, including cache, 
unless I'm updating (I build in tmpfs so usage goes up then, tho rarely 
above 12-14 GiB), tho I run multiple partitions and mount some of them 
only when needed, unmounting when done, so my cache usage is reasonably 
conservative, and as I said, I run apps on demand and shut them down when 
done, as well, so app usage is relatively conservative as well.

I'd expect your usage to be rather higher with so many windows open, 
likely into swap if you're only running 4-8 GiB of RAM.

> These are regressions from behaviors that USED to be fine (mostly in
> KDE3 where on a much less substantial machine than what i have now, i
> never had any issues of unresponsiveness.  yes, Firefox has had a role
> in creating unresponsiveness), but in jumping from Debian Jessie to
> Stretch, i'm finding a lot of little issues in Plasma5 that i do NOT
> want to throw at my users yet, and am being forced to evaluate
> alternative DEs.  (SDDM is god awful slow and the cursor can take tens
> of seconds to show up sometimes, KDE session initialization takes much
> longer than KDE4, race conditions can cause context bubble windows to
> get permanently stuck on the plasma-desktop, etc.)

I've not noticed that, but I've been running the main system on SSD for I 
think about four years now, and recently upgraded the larger media and 
backups partitions to ssd as well, so am all-ssd now.

What I *have* noticed is that if I login and run startx (which starts a 
kde/plasma session as my user, I don't use a *DM graphical login) too 
quickly, the Radeon graphics will have apparently not fully initialized, 
and plasma comes up with effects disabled.  Then I have to enable them 
and restart superkaramba (which is kde4-based and EOL with no proper 
frameworks5 alternative, unfortunately) in ordered to get transparency 
for its window, since it checks for support at init.

Similarly, even if effects come up fine, often xembedsniproxy (the 
"legacy" systray app proxy) dies and I have to restart it, to get the 
full set of tray icons including the gtk2-based pan and claws tray icons 
for may news/feeds/mail apps.

But kde/plasma starts up within a few seconds, "fast enough" it doesn't 
seem too long for me.  Tho admittedly it did take a bit back when I was 
still on spinning rust, but that has been a few years now, so I've no 
idea what it'd be like now.

> [VersionInfo]
> Qt: 5.7.1 KDE Frameworks: 5.28.0 plasmashell: 5.8.6

Also qt 5.7.1 here.  5.8 had major issues with kde and has been skipped 
by most distros, and the 5.9 LTS, while initially released the end of May 
(2017), is still being integrated by most distros, including gentoo, 
where it's apparently still only available in the gentoo/qt overlay, not 
in the main tree, even masked for testing, yet.

As I said above, live-git kde frameworks/plasma/apps here, with 
plasmashell reporting 5.10.90, pre-release for the 5.11 series, and I'm 
not sure how to check what frameworks report themselves as, other than as 
a git commit.

Actually... I just found that konsole's about konsole dialog lists 
frameworks version on the libraries tab, which says...  Frameworks 5.37.0.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman