Is this happening with other wine apps?

(In reply to Michail Vourlakos from comment #1)
> Is this happening with other wine apps?

Sorry for the late reply.

I have been doing more testing, and no... actually is the only wine app that does this. ( but i only have that wine, tested system explorer.exe and notepad.exe and doesn't do it ).

Then I noticed, that app in question changes the titlebar text every second ( has a clock in the titlebar ). Could this be what latte-dock is updating ?

(In reply to Alexandre Pereira from comment #2)
> (In reply to Michail Vourlakos from comment #1)
> > Is this happening with other wine apps?
>
> Then I noticed, that app in question changes the titlebar text every second
> ( has a clock in the titlebar ). Could this be what latte-dock is updating ?

it can be the reason. try the following:

1. close Latte
2. add a default plasma panel that contains the default plasma taskmanager
3. do you get same cpu usage with plasmashell process?

(In reply to Michail Vourlakos from comment #3)
> (In reply to Alexandre Pereira from comment #2)
> > (In reply to Michail Vourlakos from comment #1)
> > > Is this happening with other wine apps?
> >
> > Then I noticed, that app in question changes the titlebar text every second
> > ( has a clock in the titlebar ). Could this be what latte-dock is updating ?
> 
> it can be the reason. try the following:
> 
> 1. close Latte
> 2. add a default plasma panel that contains the default plasma taskmanager
> 3. do you get same cpu usage with plasmashell process?

I added two taskbars to the desktop, one "Icon Only Taskbar" and "Taskbar" ( normal one ).

plasmashell didn't seem to increase usage, using 0% to 1% . latte-dock to 3% to 5%.

(In reply to Alexandre Pereira from comment #4)
> (In reply to Michail Vourlakos from comment #3)
> > (In reply to Alexandre Pereira from comment #2)
> > > (In reply to Michail Vourlakos from comment #1)
> > > > Is this happening with other wine apps?
> I added two taskbars to the desktop, one "Icon Only Taskbar" and "Taskbar" (
> normal one ).
> 
> plasmashell didn't seem to increase usage, using 0% to 1% . latte-dock to 3%
> to 5%.

that does not mean that the app or wine do not break some X11 protocol by using it too often. But the only way to confirm this is by using that specific app under plasma 5.14

more testing: 

With more windows ( with 3 windows running ), plasmashell keeps using 0%~1% cpu, but latte-dock increases to 10%~15%.

Seems for each windows, latte-dock increases around 5% cpu.

testing with plasma 5.14 beta1

unfortunatly the app is a subscription based app ( I am paying for using the app, which is vital for work )

Is there any way I can help debugging what latte-dock is doing ?

I can't think of any other way, isn't providing any trial version?

It does have a trial, but its a once, for 2 weeks.

Can you make a patch/version that outputs more debug into the terminal ? Or can you tell me where to look for/ which function to analyse, and I will do some tests of my own ?

(In reply to Alexandre Pereira from comment #9)
> It does have a trial, but its a once, for 2 weeks.
> 
> Can you make a patch/version that outputs more debug into the terminal ? Or
> can you tell me where to look for/ which function to analyse, and I will do
> some tests of my own ?

Latte under X is doing the following: 
X11 events are sent through KWin to Latte Dock, the function for windowChanged events are sent through: https://phabricator.kde.org/source/latte-dock/browse/master/app/xwindowinterface.cpp$343

my guess is that specific app is sending too many x events with no real reason...

I tried "strace latte-dock" in a terminal window.
There is definitly different behaviour when idle before and after opening "SierraCharts" wine app.

I did a video of it, "SierraCharts" app is openned around 17s of the video. : https://youtu.be/1Yr4U4QOC4k

Also found out its just main "SierraCharts" window ( MDI style window, it has "detachable" windows, and those are not a problem ).

(In reply to Michail Vourlakos from comment #10)
> (In reply to Alexandre Pereira from comment #9)
> > It does have a trial, but its a once, for 2 weeks.
> > 
> > Can you make a patch/version that outputs more debug into the terminal ? Or
> > can you tell me where to look for/ which function to analyse, and I will do
> > some tests of my own ?
> 
> Latte under X is doing the following: 
> X11 events are sent through KWin to Latte Dock, the function for
> windowChanged events are sent through:
> https://phabricator.kde.org/source/latte-dock/browse/master/app/
> xwindowinterface.cpp$343
> 
> my guess is that specific app is sending too many x events with no real
> reason...

thanks, I will try to catch the culprit in those functions

(In reply to Alexandre Pereira from comment #11)
> I tried "strace latte-dock" in a terminal window.
> There is definitly different behaviour when idle before and after opening
> "SierraCharts" wine app.
> 
> I did a video of it, "SierraCharts" app is openned around 17s of the video.
> : https://youtu.be/1Yr4U4QOC4k
> 
> Also found out its just main "SierraCharts" window ( MDI style window, it
> has "detachable" windows, and those are not a problem ).

please dont use youtube for issues...
it creates bad marketing and it creates a sense that Latte is full of bugs... 
best way, upload your video at dropbox or google drive and create a link to share it...

from the video I cant understand much...
you must create debug messages in that function in order to distinguish the specific window creating issues and the event that is using, and why is using that event etc. etc...

(In reply to Michail Vourlakos from comment #13)
> (In reply to Alexandre Pereira from comment #11)
> > I tried "strace latte-dock" in a terminal window.
> > There is definitly different behaviour when idle before and after opening
> > "SierraCharts" wine app.
> > 
> > I did a video of it, "SierraCharts" app is openned around 17s of the video.
> > : https://youtu.be/1Yr4U4QOC4k
> > 
> > Also found out its just main "SierraCharts" window ( MDI style window, it
> > has "detachable" windows, and those are not a problem ).
> 
> please dont use youtube for issues...
> it creates bad marketing and it creates a sense that Latte is full of
> bugs... 
> best way, upload your video at dropbox or google drive and create a link to
> share it...
> 
> from the video I cant understand much...
> you must create debug messages in that function in order to distinguish the
> specific window creating issues and the event that is using, and why is
> using that event etc. etc...

Sorry, i always used youtube for these kind of things. But the video isn't public, you can only see it if you have the link.

ok, so I added some debug in the file you mentioned, and you were right.

its always looping really fast:

[debug 13:12:58.851851] - windowChangedProxy: if (std::find(m_docks.cbegin(), m_docks.cend(), wid) != m_docks.cend())
[debug 13:12:58.851851] - windowChangedProxy: if (winType != -1 && (winType & NET::Desktop)) {
[debug 13:12:58.851851] - windowChangedProxy: if (prop1 == 0 && (prop2 == NET::WM2UserTime || prop2 == NET::WM2IconPixmap)) {
[debug 13:12:58.851851] - windowChangedProxy: if (prop1 && !(prop1 & NET::WMState || prop1 & NET::WMGeometry || prop1 & NET::ActiveWindow))
[debug 13:12:58.852852] - windowChangedProxy: if (std::find(m_docks.cbegin(), m_docks.cend(), wid) != m_docks.cend())
[debug 13:12:58.852852] - windowChangedProxy: if (winType != -1 && (winType & NET::Desktop)) {
[debug 13:12:58.852852] - windowChangedProxy: if (prop1 == 0 && (prop2 == NET::WM2UserTime || prop2 == NET::WM2IconPixmap)) {
[debug 13:12:58.852852] - windowChangedProxy: if (prop1 && !(prop1 & NET::WMState || prop1 & NET::WMGeometry || prop1 & NET::ActiveWindow))
[debug 13:12:58.852852] - windowChangedProxy: if (std::find(m_docks.cbegin(), m_docks.cend(), wid) != m_docks.cend())
[debug 13:12:58.852852] - windowChangedProxy: if (winType != -1 && (winType & NET::Desktop)) {
[debug 13:12:58.852852] - windowChangedProxy: if (prop1 == 0 && (prop2 == NET::WM2UserTime || prop2 == NET::WM2IconPixmap)) {
[debug 13:12:58.852852] - windowChangedProxy: if (prop1 && !(prop1 & NET::WMState || prop1 & NET::WMGeometry || prop1 & NET::ActiveWindow))
[debug 13:12:58.852852] - windowChangedProxy: emit windowChanged(wid);
[debug 13:12:58.853853] - windowChangedProxy: if (std::find(m_docks.cbegin(), m_docks.cend(), wid) != m_docks.cend())
[debug 13:12:58.853853] - windowChangedProxy: if (winType != -1 && (winType & NET::Desktop)) {
[debug 13:12:58.853853] - windowChangedProxy: if (prop1 == 0 && (prop2 == NET::WM2UserTime || prop2 == NET::WM2IconPixmap)) {
[debug 13:12:58.853853] - windowChangedProxy: if (prop1 && !(prop1 & NET::WMState || prop1 & NET::WMGeometry || prop1 & NET::ActiveWindow))
[debug 13:12:58.853853] - windowChangedProxy: emit windowChanged(wid);
[debug 13:12:59.469469] - windowChangedProxy: if (std::find(m_docks.cbegin(), m_docks.cend(), wid) != m_docks.cend())
[debug 13:12:59.469469] - windowChangedProxy: if (winType != -1 && (winType & NET::Desktop)) {
[debug 13:12:59.469469] - windowChangedProxy: if (prop1 == 0 && (prop2 == NET::WM2UserTime || prop2 == NET::WM2IconPixmap)) {
[debug 13:12:59.469469] - windowChangedProxy: if (prop1 && !(prop1 & NET::WMState || prop1 & NET::WMGeometry || prop1 & NET::ActiveWindow))
[debug 13:12:59.469469] - windowChangedProxy: if (std::find(m_docks.cbegin(), m_docks.cend(), wid) != m_docks.cend())
[debug 13:12:59.469469] - windowChangedProxy: if (winType != -1 && (winType & NET::Desktop)) {
[debug 13:12:59.469469] - windowChangedProxy: if (prop1 == 0 && (prop2 == NET::WM2UserTime || prop2 == NET::WM2IconPixmap)) {


The weird thing about it, is, plasmashell is completly silent. ( again i have a video of it :P ).

So having latte-dock running and plasma taskbar-icons only, plasmashell doesn't even use 1%, while latte-dock is always 5% and above, with debug info spamming those messages like crazy

btw, here is the video link:

https://drive.google.com/file/d/1GS13ZZMKeKgwzZbRSma23CXsEIb4QKX7/view?usp=sharing

(In reply to Alexandre Pereira from comment #14)
> (In reply to Michail Vourlakos from comment #13)
> > (In reply to Alexandre Pereira from comment #11)
> 
> The weird thing about it, is, plasmashell is completly silent. ( again i
> have a video of it :P ).
> 
> So having latte-dock running and plasma taskbar-icons only, plasmashell
> doesn't even use 1%, while latte-dock is always 5% and above, with debug
> info spamming those messages like crazy

plasma does not support dodge modes...
dodge modes need from the window manager to send information about the window geometries and their states..

based on the code in that function and your output:

emit windowChanged(wid); //is reached that means that this specific application is sending events all the time that from Latte are considered acceptable...

These types are considered ok  NET::WMState, NET::WMGeometry, NET::ActiveWindow

Can you check which event is it and its value if it is possible?

(In reply to Michail Vourlakos from comment #16)
> (In reply to Alexandre Pereira from comment #14)
> > (In reply to Michail Vourlakos from comment #13)
> > > (In reply to Alexandre Pereira from comment #11)
> > 
> > The weird thing about it, is, plasmashell is completly silent. ( again i
> > have a video of it :P ).
> > 
> > So having latte-dock running and plasma taskbar-icons only, plasmashell
> > doesn't even use 1%, while latte-dock is always 5% and above, with debug
> > info spamming those messages like crazy
> 
> plasma does not support dodge modes...
> dodge modes need from the window manager to send information about the
> window geometries and their states..
> 
> based on the code in that function and your output:
> 
> emit windowChanged(wid); //is reached that means that this specific
> application is sending events all the time that from Latte are considered
> acceptable...
> 
> These types are considered ok  NET::WMState, NET::WMGeometry,
> NET::ActiveWindow
> 
> Can you check which event is it and its value if it is possible?

Its always a: WMState event

This is what I am getting:

[debug 13:46:43.304304] - Prop1:  QFlags(0x8000) Prop2 QFlags()
[debug 13:46:43.305305] - Prop1:  QFlags(0x20000000) Prop2 QFlags()
[debug 13:46:43.306306] - Prop1:  QFlags(0x8000) Prop2 QFlags()
[debug 13:46:43.306306] - Prop1:  QFlags() Prop2 QFlags(0x40000)
[debug 13:46:43.306306] - windowChangedProxy: emit windowChanged(wid);  QFlags() QFlags() QFlags()
[debug 13:46:43.307307] - Prop1:  QFlags(0x80000) Prop2 QFlags()
[debug 13:46:43.307307] - WMState
[debug 13:46:43.307307] - windowChangedProxy: emit windowChanged(wid);  QFlags(0x80000) QFlags() QFlags()
[debug 13:46:43.808808] - Prop1:  QFlags(0x8000) Prop2 QFlags()
[debug 13:46:43.808808] - Prop1:  QFlags(0x20000000) Prop2 QFlags()
[debug 13:46:43.809809] - Prop1:  QFlags(0x8000) Prop2 QFlags()
[debug 13:46:43.809809] - Prop1:  QFlags() Prop2 QFlags(0x40000)
[debug 13:46:43.809809] - windowChangedProxy: emit windowChanged(wid);  QFlags() QFlags() QFlags()
[debug 13:46:43.809809] - Prop1:  QFlags(0x80000) Prop2 QFlags()
[debug 13:46:43.809809] - WMState
[debug 13:46:43.809809] - windowChangedProxy: emit windowChanged(wid);  QFlags(0x80000) QFlags() QFlags()
[debug 13:46:44.305305] - Prop1:  QFlags(0x8000) Prop2 QFlags()
[debug 13:46:44.305305] - Prop1:  QFlags(0x20000000) Prop2 QFlags()
[debug 13:46:44.306306] - Prop1:  QFlags(0x8000) Prop2 QFlags()
[debug 13:46:44.306306] - Prop1:  QFlags() Prop2 QFlags(0x40000)
[debug 13:46:44.306306] - windowChangedProxy: emit windowChanged(wid);  QFlags() QFlags() QFlags()
[debug 13:46:44.307307] - Prop1:  QFlags(0x80000) Prop2 QFlags()
[debug 13:46:44.307307] - WMState


With debug of prop1 and prop2 at the start of the function. 
removed other debugs and tested of those 3 states, before debug of emit windowChanged(wid)

You can the following:

KWindowInfo info(wid, NET::WMState);
if (info.valid()) {
    qDebug() << "Modal : " << info.hasState(NET::Modal); 
    qDebug() << "Demands attention : " << info.hasState(NET::DemandsAttention);
    ..... 
}

all available states can be found at: https://api.kde.org/frameworks/kwindowsystem/html/classNET.html#a08dce7f5ea8a2a6d1d38aea3498f00ee


can you identify which state(s) create these messages?

[debug 14:23:24.305305] - Modal :  false
[debug 14:23:24.305305] - Demands attention :  false
[debug 14:23:24.305305] - Prop1:  QFlags(0x8000) Prop2 QFlags()
[debug 14:23:24.306306] - Modal :  false
[debug 14:23:24.306306] - Demands attention :  false
[debug 14:23:24.306306] - Prop1:  QFlags(0x20000000) Prop2 QFlags()
[debug 14:23:24.306306] - Modal :  false
[debug 14:23:24.306306] - Demands attention :  false
[debug 14:23:24.306306] - Prop1:  QFlags(0x8000) Prop2 QFlags()
[debug 14:23:24.306306] - Modal :  false
[debug 14:23:24.306306] - Demands attention :  false
[debug 14:23:24.306306] - Prop1:  QFlags() Prop2 QFlags(0x40000)
[debug 14:23:24.307307] - windowChangedProxy: emit windowChanged(wid);  QFlags() QFlags() QFlags()
[debug 14:23:24.307307] - Modal :  false
[debug 14:23:24.307307] - Demands attention :  false
[debug 14:23:24.307307] - Prop1:  QFlags(0x80000) Prop2 QFlags()
[debug 14:23:24.307307] - WMState
[debug 14:23:24.307307] - windowChangedProxy: emit windowChanged(wid);  QFlags(0x80000) QFlags() QFlags()
[debug 14:23:24.808808] - Modal :  false
[debug 14:23:24.808808] - Demands attention :  false
[debug 14:23:24.808808] - Prop1:  QFlags(0x8000) Prop2 QFlags()
[debug 14:23:24.808808] - Modal :  false
[debug 14:23:24.808808] - Demands attention :  false
[debug 14:23:24.808808] - Prop1:  QFlags(0x20000000) Prop2 QFlags()
[debug 14:23:24.809809] - Modal :  false
[debug 14:23:24.809809] - Demands attention :  false
[debug 14:23:24.809809] - Prop1:  QFlags(0x8000) Prop2 QFlags()
[debug 14:23:24.809809] - Modal :  false
[debug 14:23:24.809809] - Demands attention :  false
[debug 14:23:24.809809] - Prop1:  QFlags() Prop2 QFlags(0x40000)
[debug 14:23:24.809809] - windowChangedProxy: emit windowChanged(wid);  QFlags() QFlags() QFlags()


Sorry, but this is much of my area of coding, how do I see the QFlags info ?

Git commit 16384499970fa2c838cbc042c7a338b030348cab by Michail Vourlakos.
Committed on 06/10/2018 at 13:28.
Pushed by mvourlakos into branch 'master'.

imrove windowChanged signal under X11

--the new code contains more comments and except
blacklisting all NET::Properties2 signals that are
not accompanied with NET::Properties it also
whitelists specific states for NET::WMState.
This should lower a lot the calculations needed
in order to support the dodge visibility modes.
At the same time apps that are abusing X11 signals
should be ignored totally because the whitelisted
states and NET::Properties are only set by the
user or the window manager.
FIXED-IN: 0.8.2

M  +23   -3    app/xwindowinterface.cpp

https://commits.kde.org/latte-dock/16384499970fa2c838cbc042c7a338b030348cab

(In reply to Alexandre Pereira from comment #20)

please can you test again master version and see if we fixed it or at least that 

emit windowChanged(wid);

is not triggered any more?

Git commit 9613531651e737e50d5c1fdcc2dcfab000f30d46 by Michail Vourlakos.
Committed on 06/10/2018 at 13:35.
Pushed by mvourlakos into branch 'v0.8'.

imrove windowChanged signal under X11

--the new code contains more comments and except
blacklisting all NET::Properties2 signals that are
not accompanied with NET::Properties it also
whitelists specific states for NET::WMState.
This should lower a lot the calculations needed
in order to support the dodge visibility modes.
At the same time apps that are abusing X11 signals
should be ignored totally because the whitelisted
states and NET::Properties are only set by the
user or the window manager.
FIXED-IN: 0.8.2

M  +23   -3    app/xwindowinterface.cpp

https://commits.kde.org/latte-dock/9613531651e737e50d5c1fdcc2dcfab000f30d46

I just tested master and unfortunatly doesn't solve it.

I made more 2 debug tests:

1- windowChangedProxy is always being spammed and called
2- even with 

void XWindowInterface::windowChangedProxy(WId wid, NET::Properties prop1, NET::Properties2 prop2)
{
    return;
}

code, it still uses around the same cpu. I think the main problem was not the code from that function.....

I think its using a little less now, but still around 4%~5%

Also, more info:

I made a debug print on every function call of that file. only windowChangedProxy was "spammed".

Also, I tested disabling (removing) the windowChangedProxy signal connect, so its not called now, and it still is using 4%~5% cpu !

Nevermind, I must have been messing the builds on system.

Yes, its fixed :)

I am doing more investigations on this.

Right now I have latte-dock using between 0%~1% cpu with 2 windows. most of the time its at 0%. But its like this because I "rm -rf .config/latte*".

Restoring the config I had, reverts back to the old behaviour of using 4%~5% cpu.

I am gonna go through every checkbox to see if I can find out why this is happening.

Sorry for the bad work as a bug reporter ... and thank you for your help ! I will try to get more usefull info

Ok, found out how to make latte-dock use less cpu: unpin all my latte-dock pinned launchers.

That made it almost use no cpu.

(In reply to Alexandre Pereira from comment #28)
> Ok, found out how to make latte-dock use less cpu: unpin all my latte-dock
> pinned launchers.
> 
> That made it almost use no cpu.

and now try to reproduce with plasma panels and plasma taskmanager

(In reply to Michail Vourlakos from comment #29)
> (In reply to Alexandre Pereira from comment #28)
> > Ok, found out how to make latte-dock use less cpu: unpin all my latte-dock
> > pinned launchers.
> > 
> > That made it almost use no cpu.
> 
> and now try to reproduce with plasma panels and plasma taskmanager

Sorry for the delay.

So I tested what you asked.

Added some 20 launchers to the plasma "taskbar icons only" plasmoid.

It did increase plasmashell usage, from 0%~0.7% to 0%~2%. Latte-dock was at 6%~7% at this time.

Then I went into windows rules, and made wine apps skip taskbar/pager/window change. This made plasmashell drop back to 0%~0.7% like before, making the problem go away. Latte-dock continued using the same 6%~7%.

I don't mind making that rule of wine apps skipping taskbar. I was using the skip taskbar rule in plasma 5.13 and before. It seems that going to plasma 5.14, that rule got ignored in latte-dock somehow ( or plasma devs changed their api ).

Makes sense, since in the "strace video", all latte-dock was doing when I added the wine apps was looking for "desktop files" ( while without the wine app, it didnt showed that search ).

no idea... I suppose that when plasma 5.14 arrives in my system and to more users systems this could be tracked down...

until then, no more commit will be applied, I will need a way to reproduce in my system...

ok, i understand, its a corner case that you can't even test in your system.

thanks for all the assistance ! if i find out something interesting I will let you know.

Freaking nailed it, found out what was the problem

See video : https://drive.google.com/open?id=10Q9pNV959RyGSCbr6fh9WPJEQSXdQudC 

Don't know why that started to be a problem. Those rules are actually from a kde plasma 5.13 instalation which works well with them. ( i use 2 distros, one stable and one very edgy , latte-dock doesn't show cpu usage with them )

Sorry for the trouble, seems latte-dock is innocent :)

More info:

Seems the problem goes away with that checkbox because kwin stops detecting that window.

More testing, shows that there is a problem with multiple rules for the same app/window, starting 5.14.

Somewhat, this is definitly kwin rules caused.

Hi,

Can you give some info as how and where it was resolved ?

I still suffer from this problem :( Only workaround I found was using the app through explorer.exe virtual desktop, but its bad, wine's virtual desktop is really bad at managing windows :( ( really hurts my workflow ).

(In reply to Alexandre Pereira from comment #35)
> Hi,
> 
> Can you give some info as how and where it was resolved ?
> 
> I still suffer from this problem :( Only workaround I found was using the
> app through explorer.exe virtual desktop, but its bad, wine's virtual
> desktop is really bad at managing windows :( ( really hurts my workflow ).

It could be, does that application has an option to hide that clock in order to check this out?

Unfortunatly i cannot hide the clock ( and whats even worse, the title has clock and network packets info ).

I did a test, which some 6 konsole windows running "qdbus $KONSOLE_DBUS_SERVICE $KONSOLE_DBUS_SESSION org.kde.konsole.Session.setTitle 1 (date +%s%N)" each 0.1 seconds.

The increase of cpu usage got around to 3, 4%. At least this is something you can test in your system.

(In reply to Alexandre Pereira from comment #37)
> Unfortunatly i cannot hide the clock ( and whats even worse, the title has
> clock and network packets info ).
> 
> I did a test, which some 6 konsole windows running "qdbus
> $KONSOLE_DBUS_SERVICE $KONSOLE_DBUS_SESSION org.kde.konsole.Session.setTitle
> 1 (date +%s%N)" each 0.1 seconds.
> 
> The increase of cpu usage got around to 3, 4%. At least this is something
> you can test in your system.

are you sure about that command?

it returns:
bash: syntax error near symbol «(»

sorry, the command is correct, but only for fish shell.

for bash its :

qdbus $KONSOLE_DBUS_SERVICE $KONSOLE_DBUS_SESSION org.kde.konsole.Session.setTitle 1 `date +%s%N`

what I do is create a date.sh with
#! /bin/bash
qdbus $KONSOLE_DBUS_SERVICE $KONSOLE_DBUS_SESSION org.kde.konsole.Session.setTitle 1 `date +%s%N`

and then chmod +x date.sh and watch -n 1 ./date.sh

Also, sorry, in konsole, options for title be app name to be disabled ( or else, the title will always be the app running )

(In reply to Alexandre Pereira from comment #39)
> sorry, the command is correct, but only for fish shell.
> 
> for bash its :
> 
> qdbus $KONSOLE_DBUS_SERVICE $KONSOLE_DBUS_SESSION
> org.kde.konsole.Session.setTitle 1 `date +%s%N`
> 
> what I do is create a date.sh with
> #! /bin/bash
> qdbus $KONSOLE_DBUS_SERVICE $KONSOLE_DBUS_SESSION
> org.kde.konsole.Session.setTitle 1 `date +%s%N`
> 
> and then chmod +x date.sh and watch -n 1 ./date.sh

trying your code and one that I created all of them return in my system the following result by using ksysguard in order to watch the processes. Take note that to test I run Latte with Default layout and a plasma panel that contains a plasma taskmanager. I used 0.1 at watch in order to make it heavier:

1. Latte Dock remains at 1%
2. Plasmashell remains at 1%
3. kwin_x11 process goes crazy at 9%

are these your finding?

from my results it is pretty clear that this app break kwin and x11 behavior so this is probably this app fault, it is probably not even KWin fault...

Finally, been doing more testing and am able to reproduce with konsole.
OK, so no need to open lots of konsole apps, only 1 or 2 will suffice ( i test with 2 because I run sometimes 2 windows of the wine app ).

So, run 2 konsole's changing the title every second. Now with that done, the tricky part is : create kwin rules that affect those konsole windows.

I am uploading my kwin rules , you can import it, just check the activity and vd's and adapt it to your configs.

With that done ( konsole changing titles every second, and kwin rules affecting those 2 konsole windows ), latte-dock spikes to 10% cpu usage and never less.

So, it happens even with kde ( Qt ) apps, so its definitly not "wine or specific app" related.

I am gonna test next custom "title update frequency values"

Created attachment 117964 [details]
kwin rule affecting konsole

OK, more testing:

setting update frequency to 5 seconds, latte-dock usage is almost none, being at 0% most of the time and then from time to time ( i guess 5 seconds ) a 2% usage.

If you are having trouble reproducing the issue, I can make a video, showing:

* Konsole updating every 0.1 seconds but kwin konsole rules disabled -> latte-dock no cpu usage
* Konsole NOT updating title but kwin konsole rules enabled -> latte-dock no cpu usage

* Konsole updating title every 0.1 seconds and kwin konsole rules enabled -> latte-dock at least 10% cpu usage always.

Next I will try to check every kwin rule, and see if its a particular one !

(In reply to Alexandre Pereira from comment #44)
> OK, more testing:
> 
> setting update frequency to 5 seconds, latte-dock usage is almost none,
> being at 0% most of the time and then from time to time ( i guess 5 seconds
> ) a 2% usage.
> 
> If you are having trouble reproducing the issue, I can make a video, showing:
> 
> * Konsole updating every 0.1 seconds but kwin konsole rules disabled ->
> latte-dock no cpu usage
> * Konsole NOT updating title but kwin konsole rules enabled -> latte-dock no
> cpu usage
> 
> * Konsole updating title every 0.1 seconds and kwin konsole rules enabled ->
> latte-dock at least 10% cpu usage always.
> 
> Next I will try to check every kwin rule, and see if its a particular one !

what is your kwin usage?

(In reply to Michail Vourlakos from comment #45)
> (In reply to Alexandre Pereira from comment #44)
> > OK, more testing:
> > 
> > setting update frequency to 5 seconds, latte-dock usage is almost none,
> > being at 0% most of the time and then from time to time ( i guess 5 seconds
> > ) a 2% usage.
> > 
> > If you are having trouble reproducing the issue, I can make a video, showing:
> > 
> > * Konsole updating every 0.1 seconds but kwin konsole rules disabled ->
> > latte-dock no cpu usage
> > * Konsole NOT updating title but kwin konsole rules enabled -> latte-dock no
> > cpu usage
> > 
> > * Konsole updating title every 0.1 seconds and kwin konsole rules enabled ->
> > latte-dock at least 10% cpu usage always.
> > 
> > Next I will try to check every kwin rule, and see if its a particular one !
> 
> what is your kwin usage?

usually between 0 and 1% ( when I am just letting testing run and not moving windows or etc ).

I think I solved it ( I can be wrong, as the history of this bug report shows )

I think the latte-dock high cpu usage with when kwin is using a rule that compares the title.

So in the konsole test, i removed the title comparison rule and it stopped using high cpu. Also with my custom wine app it did the same !

(In reply to Alexandre Pereira from comment #47)
> I think I solved it ( I can be wrong, as the history of this bug report
> shows )
> 
> I think the latte-dock high cpu usage with when kwin is using a rule that
> compares the title.
> 
> So in the konsole test, i removed the title comparison rule and it stopped
> using high cpu. Also with my custom wine app it did the same !

what is happening is that your app is changing too often its title with no reason (probably because of the time shown). Each time because the title is changes the kwin rule needs to recheck if the kwin rule criteria are still applied and this goes on forever until the app is closed.

Latte cant do something about it, only way is if KWin blocks this or the app does not send all these signals all the time

(In reply to Michail Vourlakos from comment #48)
> (In reply to Alexandre Pereira from comment #47)
> > I think I solved it ( I can be wrong, as the history of this bug report
> > shows )
> > 
> > I think the latte-dock high cpu usage with when kwin is using a rule that
> > compares the title.
> > 
> > So in the konsole test, i removed the title comparison rule and it stopped
> > using high cpu. Also with my custom wine app it did the same !
> 
> what is happening is that your app is changing too often its title with no
> reason (probably because of the time shown). Each time because the title is
> changes the kwin rule needs to recheck if the kwin rule criteria are still
> applied and this goes on forever until the app is closed.
> 
> Latte cant do something about it, only way is if KWin blocks this or the app
> does not send all these signals all the time

I understand, but please take in mind that latte-dock is the only process suffering from this high cpu. kwin-x11 continues using 0~1% cpu, when the problem is happening. Also plasma shell with a icon only task manager into it, sticks to 0~2% cpu usage ( tested with 10 konsole windows ).

Maybe better closing it as WONTFIX, since its a problem that can happen to any app ( Qt , gtk or etc ) that changes title very much, and with a kwin rule into it.

To me you can keep this closed, since now I know exactly how to avoid this issue, so I can work around it.

I will leave it open in case I find the time to investigate in order to be sure that Latte can not handle the case...

Another workaround is to keep latte-dock and kwin rules as it is (using title rules), but instead of using latte-dock taskmanager, use a latte-dock panel and then add the plasma icon taskmanager into it.

So, just replacing the latte-dock task manager to plasma task manager changed from ~70% usage to ~2% usage in latte-dock. tested this now with 6 konsole windows changing title with freq of 0.1 secs.

(In reply to Alexandre Pereira from comment #51)
> Another workaround is to keep latte-dock and kwin rules as it is (using
> title rules), but instead of using latte-dock taskmanager, use a latte-dock
> panel and then add the plasma icon taskmanager into it.
> 
> So, just replacing the latte-dock task manager to plasma task manager
> changed from ~70% usage to ~2% usage in latte-dock. tested this now with 6
> konsole windows changing title with freq of 0.1 secs.

in that case this is a plasmoid issue and we should be able to fix

(In reply to Michail Vourlakos from comment #52)
> (In reply to Alexandre Pereira from comment #51)
> > Another workaround is to keep latte-dock and kwin rules as it is (using
> > title rules), but instead of using latte-dock taskmanager, use a latte-dock
> > panel and then add the plasma icon taskmanager into it.
> > 
> > So, just replacing the latte-dock task manager to plasma task manager
> > changed from ~70% usage to ~2% usage in latte-dock. tested this now with 6
> > konsole windows changing title with freq of 0.1 secs.
> 
> in that case this is a plasmoid issue and we should be able to fix

Great ! Plasma icon taskmanager works, but latte-dock taskmanager plasmoid is soo much better !

Actually you don't need my kwin rules, all you need is a rule based on title and some setting forcing something ( like size, position, keep above, etc ).

Creating a rule based on title substring but not making any setting on it will not trigger the cpu usage.

Were you able to reproduce it in your machine ?

(In reply to Alexandre Pereira from comment #53)
> (In reply to Michail Vourlakos from comment #52)
> > (In reply to Alexandre Pereira from comment #51)
> Were you able to reproduce it in your machine ?

not yet, do you have an easier reproducible way than the previous one?

in what way ? the app changing its title ? or the kwin rules part ?
if the app changing its title, i will search for an easier way

Created attachment 117967 [details]
kwin rule for konsole

kwin rule for konsole

Created attachment 117968 [details]
bash script for konsole testing

bash script for konsole testing

(In reply to Alexandre Pereira from comment #55)
> in what way ? the app changing its title ? or the kwin rules part ?
> if the app changing its title, i will search for an easier way

Let's try the following, I uploaded two files, with them try the following to your system:

1. import the kwin rule for konsole
2. execute in a konsole window: watch -n 0.1 ./timebug2.sh (this is the name for the bash script)

[A]. do you still get high cpu usage? In my system I cant reproduce

If [A] is YES:

[B]. please upload also you Latte layout file in order to try to reproduce in my system.

If [B] is NO:

[C]. please provide newer files for these two files I order in order to test them in my system

Created attachment 117969 [details]
latte config files

it does happen, with your kwin rules and script. So uploaded latte config files.

btw, don't know if this is important:

I was just testing with new latte-dock configs, and I noticed that if I praticly don't have any launchers pinned, it seems like it doesn't use alot of cpu ( and no problem exists ).

I generally have 15 launchers pinned at total.

(In reply to Alexandre Pereira from comment #61)
> btw, don't know if this is important:
> 
> I was just testing with new latte-dock configs, and I noticed that if I
> praticly don't have any launchers pinned, it seems like it doesn't use alot
> of cpu ( and no problem exists ).
> 
> I generally have 15 launchers pinned at total.

no idea, I loaded your layout in a multi-screen environment, two docks at one monitor and two docks at another, I run the example to test, no problem...

I really have no idea what could this be, something in the plasmoid is happening in your system but I dont know what

Did you had alot of pinned apps ? I noticed that if I "start clean" with no pinned apps, cpu usage is nowhere near as normal. Readding them makes cpu usage go again high.

Well, ok, if I am able to get more info on this and why its happening, I will post it here.

It sucks that you cannot reproduce it, makes it really hard. If I can give any more info in any way, just ask.

(In reply to Alexandre Pereira from comment #63)
> 
> It sucks that you cannot reproduce it, makes it really hard. If I can give
> any more info in any way, just ask.

yeah, if you find something new report back please,

1. If you unpin konsole does the issue remains? (in case this is not an issue of many launchers but rather the specific launcher for which the title is changing too many times)

(In reply to Michail Vourlakos from comment #64)
> (In reply to Alexandre Pereira from comment #63)
> > 
> > It sucks that you cannot reproduce it, makes it really hard. If I can give
> > any more info in any way, just ask.
> 
> yeah, if you find something new report back please,
> 
> 1. If you unpin konsole does the issue remains? (in case this is not an
> issue of many launchers but rather the specific launcher for which the title
> is changing too many times)

If i unpin konsole, the issue remais.

As a test I unpinned all my apps ( across all activities ), and usage went down to around cycling through 0, 1, 2%.

If you run latte through command prompt with, latte-dock -d

Do you get something interesting especially when the issue appears?

(In reply to Michail Vourlakos from comment #66)
> If you run latte through command prompt with, latte-dock -d
> 
> Do you get something interesting especially when the issue appears?

no, not really, no info ( different than not changing konsole title )

where it makes a diference is when doing a "strace latte-dock", but its very confusing.

(In reply to Alexandre Pereira from comment #67)
> (In reply to Michail Vourlakos from comment #66)
>

is it possible to test again with latest master?
I have just made a commit that could reduce cpu usage from windows tracking vastly

(In reply to Michail Vourlakos from comment #68)
> (In reply to Alexandre Pereira from comment #67)
> > (In reply to Michail Vourlakos from comment #66)
> >
> 
> is it possible to test again with latest master?
> I have just made a commit that could reduce cpu usage from windows tracking
> vastly

Hi,

I just tried it, before with latest "release version" ( on archlinux ) and then using the aur git package: same results.

Still, using latte-dock with a kwin rules using the title as rule, will make latte-dock use about 5% cpu for each window ( in this case i tested with 3 windows, so about 15% cpu usage ).

Removing kwin rule bounded by title ( but still with rules inforced, but only by class and executable ) made latte-dock go to 0-1% cpu usage.

Strange is, kwin rule by title with a window that is constantly changing titles, makes latte-dock high cpu usage, but not plasmashell.

I have been using latte-dock with this workaround: renamed the wine executables and then made rules based on the executables name ( and not make any specification about the titles in the rules ).

(In reply to Alexandre Pereira from comment #69)
> (In reply to Michail Vourlakos from comment #68)
> > (In reply to Alexandre Pereira from comment #67)
> > > (In reply to Michail Vourlakos from comment #66)
> > >
> > 
> > is it possible to test again with latest master?
> > I have just made a commit that could reduce cpu usage from windows tracking
> > vastly
> 
> Hi,
> 
> I just tried it, before with latest "release version" ( on archlinux ) and
> then using the aur git package: same results.
> 
> Still, using latte-dock with a kwin rules using the title as rule, will make
> latte-dock use about 5% cpu for each window ( in this case i tested with 3
> windows, so about 15% cpu usage ).
> 
> Removing kwin rule bounded by title ( but still with rules inforced, but
> only by class and executable ) made latte-dock go to 0-1% cpu usage.
> 
> Strange is, kwin rule by title with a window that is constantly changing
> titles, makes latte-dock high cpu usage, but not plasmashell.
> 
> I have been using latte-dock with this workaround: renamed the wine
> executables and then made rules based on the executables name ( and not make
> any specification about the titles in the rules ).

are you sure that the AUR git version is containing yesterday commits?

https://phabricator.kde.org/source/latte-dock/history/master/

because in this commit there is a fix for batch kwin signaling for window title changes...

(In reply to Michail Vourlakos from comment #70)
> (In reply to Alexandre Pereira from comment #69)
> > (In reply to Michail Vourlakos from comment #68)
> > > (In reply to Alexandre Pereira from comment #67)
> > > > (In reply to Michail Vourlakos from comment #66)
> > > >
> > > 
> > > is it possible to test again with latest master?
> > > I have just made a commit that could reduce cpu usage from windows tracking
> > > vastly
> > 
> > Hi,
> > 
> > I just tried it, before with latest "release version" ( on archlinux ) and
> > then using the aur git package: same results.
> > 
> > Still, using latte-dock with a kwin rules using the title as rule, will make
> > latte-dock use about 5% cpu for each window ( in this case i tested with 3
> > windows, so about 15% cpu usage ).
> > 
> > Removing kwin rule bounded by title ( but still with rules inforced, but
> > only by class and executable ) made latte-dock go to 0-1% cpu usage.
> > 
> > Strange is, kwin rule by title with a window that is constantly changing
> > titles, makes latte-dock high cpu usage, but not plasmashell.
> > 
> > I have been using latte-dock with this workaround: renamed the wine
> > executables and then made rules based on the executables name ( and not make
> > any specification about the titles in the rules ).
> 
> are you sure that the AUR git version is containing yesterday commits?
> 
> https://phabricator.kde.org/source/latte-dock/history/master/
> 
> because in this commit there is a fix for batch kwin signaling for window
> title changes...

I checked the "cache" git log, its the latest version.
latte-dock -v gives me 0.8.75

Created attachment 120359 [details]
latest git version with top

attached screenshot showing latte-dock using high cpu:

notice: Disconnecting the sierrachart app, actually makes it not constantly update the title. So at least **visibly** the title is not changing.

I wouldn't discard this being a kwin bug. the fact that it runs fine without kwin "title based rules" means that latte-dock can handle the changing titles by itself.

I don't know how more I can help, but if there is any info you need, just ask !

If you are using latest git version then the issue is different...

1. Which commit is your Latte git version using?
2. The Latte git version has stuck at 0.8.75 for more than six months so this is of no use

(In reply to Michail Vourlakos from comment #74)
> If you are using latest git version then the issue is different...
> 
> 1. Which commit is your Latte git version using?
> 2. The Latte git version has stuck at 0.8.75 for more than six months so
> this is of no use

this commit log:

commit 2a6620853b69ba1e2aa059d358bd45a33c7feac4 (HEAD -> master)
Author: Michail Vourlakos <mvourlakos@gmail.com>
Date:   Tue May 28 19:02:04 2019 +0300

    fix crash when updating Indicators packages

(In reply to Alexandre Pereira from comment #75)
> (In reply to Michail Vourlakos from comment #74)
> > If you are using latest git version then the issue is different...
> > 
> > 1. Which commit is your Latte git version using?
> > 2. The Latte git version has stuck at 0.8.75 for more than six months so
> > this is of no use
> 
> this commit log:
> 
> commit 2a6620853b69ba1e2aa059d358bd45a33c7feac4 (HEAD -> master)
> Author: Michail Vourlakos <mvourlakos@gmail.com>
> Date:   Tue May 28 19:02:04 2019 +0300
> 
>     fix crash when updating Indicators packages

In that case I have no idea about this issue and what to blame...

(In reply to Michail Vourlakos from comment #76)
> (In reply to Alexandre Pereira from comment #75)
> > (In reply to Michail Vourlakos from comment #74)
> > > If you are using latest git version then the issue is different...
> > > 
> > > 1. Which commit is your Latte git version using?
> > > 2. The Latte git version has stuck at 0.8.75 for more than six months so
> > > this is of no use
> > 
> > this commit log:
> > 
> > commit 2a6620853b69ba1e2aa059d358bd45a33c7feac4 (HEAD -> master)
> > Author: Michail Vourlakos <mvourlakos@gmail.com>
> > Date:   Tue May 28 19:02:04 2019 +0300
> > 
> >     fix crash when updating Indicators packages
> 
> In that case I have no idea about this issue and what to blame...

As a programmer, I cannot understand it also, to give you more info!! specially cannot reproduce with a more "normal app".

I was looking at the kwin code for rules, and it does has special treatment for window title matches: ( creates a queued connection that other filtering types don't create ).

```
if (titlematch != UnimportantMatch) // track title changes to rematch rules
        QObject::connect(c, &AbstractClient::captionChanged, c, &AbstractClient::evaluateWindowRules,
                         // QueuedConnection, because title may change before
                         // the client is ready (could segfault!)
static_cast<Qt::ConnectionType>(Qt::QueuedConnection|Qt::UniqueConnection));
```
but i don't know kwin programming so I don't really know.
But I just tested with creating kwin rules with title base that will never match ! ( creating a kwin title match rule with bogus impossible title ) and it still creates heavy cpu usage !

And this seems to be the only application that makes it happen!

Also, running latte-dock -dr, shows spamming of:
```
[debug 18:30:33.106106] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:33.973973] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:34.353353] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:35.054054] - WINDOW CHANGED :::  QVariant(qulonglong, 148897797)
[debug 18:30:35.973973] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:36.972972] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:37.972972] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:38.974974] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:39.972972] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:40.973973] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:41.973973] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:42.972972] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:43.972972] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:44.973973] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:45.543543] - WINDOW CHANGED :::  QVariant(qulonglong, 146800646)
[debug 18:30:45.973973] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:46.973973] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:47.972972] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:48.973973] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:49.972972] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:50.972972] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:51.972972] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
[debug 18:30:52.973973] - WINDOW CHANGED :::  QVariant(qulonglong, 150994949)
```

https://phabricator.kde.org/source/latte-dock/browse/master/app/wm/xwindowinterface.cpp$426

you can find the code from Latte handling the windowChanged signal under X11

1. Look how many checks the signals pass in order to be identified as valid
2. The last commits have added a Timer of 150ms under abstractwindowinterface in order to avoid sending a batch of signals windowChanged for the same window

So the findings are the following:
A. KWin is sending a batch of signals continuously even though it shouldnot
B. This is happening only with that specific app

C. There is the chance that this app is touching its window title all the time and KWin has no responsibility to check the Window Title is actually have changed or not


D. The only interesting part would be if you could find a workaround about how plasma libtaskmanager is not hit by it...

no news for this, I will close it until there are more specific information that are pointing of the root of the cause and where that root is found.