Summary: | regenerating high-res SVGs is slow | ||
---|---|---|---|
Product: | [Frameworks and Libraries] libplasma | Reporter: | LTHR <lanthruster> |
Component: | libplasma | Assignee: | Marco Martin <notmart> |
Status: | RESOLVED WORKSFORME | ||
Severity: | major | CC: | ahiemstra, katyaberezyaka, kde, nate, plasma-bugs |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
LTHR
2020-12-19 02:50:37 UTC
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! 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! 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. |