SUMMARY KDE Plasma 5.20.4 POPUP application launcher and other dialogs suffer from massive plasmashell renderer lockup issues mitigated by hardware OpenGL support and powerful CPUs. When a users clicks on Launch button it would first render the frame then on some computers after 5 or more seconds it the menu would appear. Then when you go to the next level the situation repeats. The second time you go through the same menu route it's faster. The same happens with some other plasma dialogs. More info: Linux 1025c 4.14.209-gentoo-x86_64 #1 SMP PREEMPT Thu Dec 10 19:00:20 MSK 2020 x86_64 Intel(R) Atom(TM) CPU N2800 @ 1.86GHz GenuineIntel GNU/Linux STEPS TO REPRODUCE 1. Find a laptop with GMA3600. 2. Turn of GMA3600 in the kerne v4.14.*l 3. Use xorg-server-1.20.8-r1 with sddm launcher and modsetting driver 4. Install KDE Plasma 5.20.4 OBSERVED RESULT Multiple lockup issues in plasmashell EXPECTED RESULT Linux/KDE Plasma: 4.14.209-gentoo-x86_64 Plasma 5.20.4 (available in About System) Qt Version: 5.15.2 ADDITIONAL INFORMATION That is certainly a bug. I experimented quite a lot with that box. It happens like in the summary with all of a sudden plasmashell taking all 100% of a CPU thread and it goes on and on and during all this time plasma gets unresponsive. Turning off Compositon or changing turning off or on effect doesn't help. The performance is all the same. It happens with some KDE apps too. Never happens with the other apps like VLC with QT5 or LXQT apps. GMA3600 in kernel support is quite fast. And ASUS 1025C 64bit platform with 4Gb of memory is very responsive. For example I'm having now 10 load average on 4 threads compiling chromium and firefox and other apps in different terminals and it responding amazingly well for that CPU. LXQT all so works staying amazingly responsive. But with plasma there is a lockpu bug. Plasma it very fast drawing windows with all the decorations and transparencies but opening a popup or initiating a some settings dialogs are causing plasmashell lockup for a period of 4 to 40 seconds. It looks like you click on a menu with only 1 item and you have to wait for 20 seconds. I have no other QT5 application that behaves the same on this box but KDE apps and plasma itself. At the same time FPS is not suffering it always as high as 25 and everything look smooth except these lockups. The logs have nothing special to tell. I've done nearly a lot of testing in the past week over this issue and nothing seems to help. The hardware platform and other apps performance and responses - outstanding but KDE plasma suffers. I'm ready to nail down this problem and provide all possible assistance to find out the cause of that. You many not notice the lags because of the the powerful CPU and hardware opengl support which GMA3600 lacks. The difference between Plasma opening a popup menu with a single item and LXQT doing the same or other QT5 apps like VLC is nearly 100 times. That is amazingly high difference not accountable by slow processor. During all that difficult times it's always plasmashell taking 100% of the thread for 5-20 seconds or more and then the menu appears.
Generally it feels like plasmashell is doing something it shouldn't. Like some logic inside doing some unnecessary job over and over again. It more feels like when you have IRQ conflict problem on a graphic card and from time to time the whole picture just locks and there is nothing you can do but wait then it unfreezes and for some time it's responsive again and then again it freezes and so it's how Plasma works but on the same PC other applications perform like x100 faster. Let's dig into this deeper I have that laptop under LXQT now which is stunning....it just feels and has optimized efficient desktop with noting extra - a cool option for a developer. May be LXQT should be adopted by plasma as plasma-lite alternative because it's certainly fills in the niche. Nevertheless it's just a bug in Plasma that makes it so different and may be we could find the cause and fix it. I'm a developer but have no experience with neither QT not Plasma. If you need some extra info - please let me know
2. Turn of GMA3600 in the kerne v4.14.*l It should be Turn ON GMA3600 support
The problem narrowed down to qtsvg? i.e. if menu items have hi-res svg file in: /usr/share/icons/hicolor/scalable/apps/*.svg and cache expired the menu rendering is slow. That is what makes KDE sluggish. Is there any way to change qtsvg cache expiration time or make it permanent or to speed up qtsvg?
Yes, it looks like all these lags are related to svg icon/theme files. I checked my e3-1270 and kde 4.14.3 and it seems it all so has a similar problem with popup but likely because of a much powerful cpu it's barely noticeable. So we're basically wasted by SVG format...
That is requiring testing: (In reply to LTHR from comment #4) > Yes, it looks like all these lags are related to svg icon/theme files. I > checked my e3-1270 and kde 4.14.3 and it seems it all so has a similar > problem with popup but likely because of a much powerful cpu it's barely > noticeable. So we're basically wasted by SVG format... Not verified with 4.14.3 may be I'm wrong about 4.14.3
There were some performance improvements here recently. See https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/168. Can you check again with Frameworks 5.78 once it's released in about two weeks? Thanks!
Certainly, as soon as I have the update in Gentoo portage tree. Alternatively I might install/compile some plasma components upon your request not waiting till the release. I'm still not able to find the exact cause of it. It feels like for some reason when a popup menu is opened or KDE System Settings are called when an icon is SVG Plasma does some super extra work, like unzipping all of svg files in the theme and the scaling them or in KDE System Settings. While menu is accessed and svg icon cache holds menu works, then icon goes out of view, caches is nullified and again that lag in menu. It's not plasma itself the problem is somewhere in how menu icons are rendered. I first it's qml but no, it's likely related to svg format. (In reply to Nate Graham from comment #6) > There were some performance improvements here recently. See > https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/168. Can > you check again with Frameworks 5.78 once it's released in about two weeks? > Thanks!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
I'm waiting for the new framework 5.78 to appear in Gentoo Portage, as soon as I have I'll provide the feedback. I'm currently installing 5.77 framework which is the latest available in the portage. And I will provide the feedback about it in a few days, after it installs. (In reply to Bug Janitor Service from comment #8) > Dear Bug Submitter, > > This bug has been in NEEDSINFO status with no change for at least > 15 days. Please provide the requested information as soon as > possible and set the bug status as REPORTED. Due to regular bug > tracker maintenance, if the bug is still in NEEDSINFO status with > no change in 30 days the bug will be closed as RESOLVED > WORKSFORME > due to lack of needed information. > > For more information about our bug triaging procedures please read the > wiki located here: > https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging > > If you have already provided the requested information, please > mark the bug as REPORTED so that the KDE team knows that the bug is > ready to be confirmed. > > Thank you for helping us make KDE software even better for everyone!
info: framework 5.77 is the same no changes with the problem compared but some good news I prepared detailed videos demonstrating the problems with PLASMA. 1025ะก performance with different panels: 1. PLASMA 5.77 http://files.healtech.ru/plasma-22-01-2021.ogv I commented the problems with the video, please watch it to the end 2. LXQT 0.16 http://files.healtech.ru/lx-qt-22-01-2021.ogv 3. XFCE 4.14.4 http://files.healtech.ru/xfce-22-01-2021.ogv I hope it helps. The top is at the background.
please let me know when OGV files are downloaded - I'll remove them
info : Freameworks 5.78 tested, the short version : absolutely no change in performance. Same problem as shown on the video above, same symptoms, same lags : KDE is still unusable on this laptop. (In reply to Nate Graham from comment #6) > There were some performance improvements here recently. See > https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/168. Can > you check again with Frameworks 5.78 once it's released in about two weeks? > Thanks!
reported
As far as I can tell, both from your video as well as from things found on the internet (https://bbs.archlinux.org/viewtopic.php?id=144445&p=6 for example), that chip does not do hardware accelerated rendering. That means things are falling back to using a CPU based version of OpenGL which is not going to be a great experience on such an old and under powered CPU. Since Plasma 5.0 and Qt 5.0 Plasma uses OpenGL for all rendering by default. One thing you could try is setting "QT_QUICK_BACKEND=software" for your session - this may make it usable again but may cause other problems depending on what you do.
Could we fall back to using the software renderer automatically if we detect hardware that's not capable of doing hardware-accelerated rendering, perhaps?
update : the same performance with 5.21.5 Just for the record : the power of that CPU is underestimated. It's a pure born linux box that works with linux better than with windows.... With CPU microcode patch it can utilize amd64 arch with 4Gb RAM and thankfully to kernel patches its graphical performance is amazing. I've built Gentoo ADM64 linux for Asus 1025c netbook and it's just something in terms of stability, consistency and performance - it plays FullHD video smoothly, runs Photoshop CS19, chromium, FF. I had a long to-do/fix list over these 6 months of working on it and the only problem I still can't fix is KDE :-( I'm ready to help.
(In reply to Nate Graham from comment #16) > Could we fall back to using the software renderer automatically if we detect > hardware that's not capable of doing hardware-accelerated rendering, perhaps? Or have an option in KDE config.... May be I'm wrong but it looks like a bug. Section "Device" Identifier "Device0" VendorName "INTEL Corporation" BoardName "GMA 3600 [GMA500]" Driver "modesetting" Option "AccelMethod" "glamor" # Option "SWCursor" "ON" Option "DPMS" "TRUE" Option "DRI" "3" EndSection DRI3 is fine, glxgears is fine, FULL HD video is fine, Photoshop 19 is fine, smooth graphics, LXQT - fine, XFCE - fine, chromium - smooth graphics and performance, firefox - smooth graphics, not much CPU usage from any of them. I can't image how normally plasmashell can consume more CPU than chromium with 50+ tabs opened for 5+ minutes when mouse is rolled over a menu item.... it's just 100% and nothing helps, that's the last thing left unsolved for this netbook. If you google you will find a lot of reports about plasmashell taking 100% of CPU all of a sudden. But randomly - the only way to fix it is to kill it. It looks very familiar to my case but in my case - it's always 100% and always re-producible. I believe it's the same bug. It can't normally be that rolling a mouse over an item it KDE menu can require the same amount of CPU as - none-accelerated Full HD VIDEO requires in 7 minutes. It must be a bug. May be fixing it will accelerate KDE to the new performance horizonts.
> When a users clicks on Launch button it would first render the frame then on some computers after 5 or more seconds This is definitely a bug. It's almost certainly not related to SVGs and it doesn't point in that direction. Performance is something we have been continually improved upon over time and continue to do so. There is nothing here which appears directly unique and actionable. I shall close this report.