Bug 154334 - Panel uses too much CPU to change window title
Summary: Panel uses too much CPU to change window title
Alias: None
Product: plasma4
Classification: Plasma
Component: panel (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: Plasma Bugs List
Depends on:
Reported: 2007-12-19 18:07 UTC by Jonathan Thomas
Modified: 2007-12-19 21:49 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Thomas 2007-12-19 18:07:08 UTC
Version:            (using KDE KDE 3.97.0)
Installed from:    Ubuntu Packages
OS:                Linux

I'm running an emulator that needs all the resources it can get a hold of. The emulator in question has it's frames per second meter in the title bar. This can change quite often, due to the nature of the emulator. (Frame rate changes a lot, therefore the window title changes a lot.)

While the emulator is running and the window title is changing, plasma is taking up 10-13% of the CPU, and I experience pauses in the emulator that occur every time the window title changes. I don't think that plasma should take up that much resource just to change the window title on the panel.

So it is my wish to have Plasma take up less resources to change the window title on the panel. Please don't take this as a complaint, I really don't mean it in that sense. I love Plasma and the thought of all the innovative applets that can be created is exciting. (I've fallen in love with the Volume Notifier applet) I would just like to give some input on areas where Plasma is sub-optimal for my daily computer usage/needs. :)

Keep up the good work, and here's to a successful KDE 4 series!
Comment 1 Aaron J. Seigo 2007-12-19 18:29:39 UTC
we'd all like every part of every app to use near-zero cpu. we could just keep an "optimize the crap out of everything" bug report open all the time, but that wouldn't be particularly useful. there is no useful target to hit with this BR other than perhaps a qualitative "ok, that's fast enough now". qualitative BRs are just very hard to address effectively because there is no set finish line.

anyways, having windows that change titles very frequently is, to be frank, stupid on the part of the application. i'll work around this in the taskbar by delaying updates so we don't repaint more than N times a second regardless of what an app does... but that's probably the best i can do in terms of concrete closing of this BR.
Comment 2 Jonathan Thomas 2007-12-19 19:42:39 UTC
Hmm, I see what you mean. I guess it might not quite be fair to compare this to Kicker and say that Kicker never had this sort of problem? :P

But thank you for at least looking in to the issue.
Comment 3 Aaron J. Seigo 2007-12-19 20:55:59 UTC
heh. actually, kicker did have this sort of problem. i optimized the living crap out of the taskbar a few years ago.
Comment 4 Aaron J. Seigo 2007-12-19 21:49:17 UTC
SVN commit 750664 by aseigo:

significantly compress update events: never repaint an item or relayout a task group more than 5 times per second.
note that we do an initial paint immediately no matter what to avoid appearing slow in the common case.
should protect us against insane applications.

 M  +66 -15    tasks.cpp  
 M  +13 -4     tasks.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=750664