| Summary: | plasmashell uses 100% of cpu for extended period when switching desktops, when a custom *.desktop file is pinned in Task Manager | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Vladimir Dergachev <volodya> |
| Component: | Task Manager and Icons-Only Task Manager widgets | Assignee: | Eike Hein <hein> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | nate, plasma-bugs-null |
| Priority: | NOR | ||
| Version First Reported In: | 5.18.7 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Light.desktop | ||
|
Description
Vladimir Dergachev
2021-12-18 16:14:21 UTC
Sorry no one got back to you about this bug earlier. Are you able to reproduce the issue with Plasma 5.27.4 or newer? Not sure - I am using Kubuntu 20.04, currently running plasma 5.18.8, Is it still the case that to try new plasmashell one needs to replace the whole KDE ? On Tue, 11 Apr 2023, Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=447184 > > Nate Graham <nate@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |nate@kde.org > > --- Comment #1 from Nate Graham <nate@kde.org> --- > Sorry no one got back to you about this bug earlier. Are you able to reproduce > the issue with Plasma 5.27.4 or newer? > > -- > You are receiving this mail because: > You reported the bug. Yes. I would strongly recommend upgrading; Plasma 5.18 has been out of support for years. If you upgrade to Kubuntu 22.04, you'll at least get Plasma 5.24, which is still out of support, but it's much newer and less buggy. And then you can upgrade to Kubuntu 23.04 once it's released this month and get Plasma 5.27, which is supported and will be supported through the end of the year at least. Created attachment 158080 [details] Light.desktop Oh, I see - is there a straightforward way to install the latest version to test without upgrading the whole distribution ? Years ago I was happily compiling KDE and it was often possible to compile one component at a time. Once I even compiled it for Solaris - was a major improvement over CDE. For me the key thing is stability of tools like gcc and system libraries - upgrading the distribution changes versions and then I need to retest my code again for speed. That's why I stick to LTS versions of Ubuntu. Btw, if you have the newest version installed, maybe you could run a quick test ? All one needs to do is to create a KDE desktop file pointing to any executable, assign an icon to it and pin it in the task manager. The if switching desktops is seamless, chances are it is fixed in the newest version. I also attached my Light.desktop file in case it is useful. thank you Vladimir Dergachev On Thu, 13 Apr 2023, Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=447184 > > Nate Graham <nate@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |WAITINGFORINFO > Status|REPORTED |NEEDSINFO > > --- Comment #3 from Nate Graham <nate@kde.org> --- > Yes. I would strongly recommend upgrading; Plasma 5.18 has been out of support > for years. If you upgrade to Kubuntu 22.04, you'll at least get Plasma 5.24, > which is still out of support, but it's much newer and less buggy. And then you > can upgrade to Kubuntu 23.04 once it's released this month and get Plasma 5.27, > which is supported and will be supported through the end of the year at least. > > -- > You are receiving this mail because: > You reported the bug. Yep, I don't experience the bug with that .desktop file pinned to my Task Manager. So let's call it fixed! It's always possible to compile a new Plasma on an old distro, but the older the distro, the harder it will be since Plasma frequently depends on relatively new versions of 3rd-party libraries. I'd file it under "possible but painful" (or adventurous, depending on how you want to look at it!). Also JFYI you probably need to be testing your code for speed and correctness with new tooling as well as old tooling, because you can't guarantee that all of your users will be using software compiled with old tooling, unless you distribute the software yourself in purely binary form. As long as the source code is available, any random distro can compile it with any tooling and package it up for consumption. On Fri, 14 Apr 2023, Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=447184 > > Nate Graham <nate@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|WAITINGFORINFO |FIXED > Status|NEEDSINFO |RESOLVED > > --- Comment #5 from Nate Graham <nate@kde.org> --- > Yep, I don't experience the bug with that .desktop file pinned to my Task > Manager. So let's call it fixed! Agreed ! > > It's always possible to compile a new Plasma on an old distro, but the older > the distro, the harder it will be since Plasma frequently depends on relatively > new versions of 3rd-party libraries. I'd file it under "possible but painful" > (or adventurous, depending on how you want to look at it!). > > Also JFYI you probably need to be testing your code for speed and correctness > with new tooling as well as old tooling, because you can't guarantee that all > of your users will be using software compiled with old tooling, unless you > distribute the software yourself in purely binary form. As long as the source > code is available, any random distro can compile it with any tooling and > package it up for consumption. No, no, this is a different situation - this is a numerical code and speed is critical, so one needs to control assembly output. So I want the C compiler to produce a binary where inner loops do exactly what I want. When you upgrade distros gcc and C libraries often have large changes. A lot of those changes are well-intentioned attempts to automatically secure programs against bugs or introduce speedups into poorly optimized programs, at the expense of numerical codes such as mine. So I compare runtime between different binaries and start digging into assembly to figure out what went wrong. This fine tuning is worthwhile because the code takes months to run. It is the results that are distributed to the users - they are portable and use MVL library (package RMVL if you use R). thank for looking into this ! Vladimir Dergachev > > -- > You are receiving this mail because: > You reported the bug. Oh wow, what an interesting use case. It's always cool to hear about all the diverse ways people use our software! |