Version: (using KDE 4.3.0) OS: Linux Installed from: Fedora RPMs Resizing a folderview (even an empty one) is quite slow, especially when the size of the folderview exceeds ~700x700px. This really destroys the user experience. I did a little bit of profiling, and those were my findings (sysprof file attached): - A lot of time is spent inside re-rendering the SVGs. - Plasma::FrameSVG is slow too. - A lot of time is spent in kernel-code, because a lot of XPutImage is happening. I wonder why all the SVG contents have to be re-generated for each resize operation. Especially for the background wouldn't it be enough to pre-genarate it and use a scaled instance of it. Once QT could use XRender to do scaling, all those operations could be hw-accelerated.
Created attachment 36151 [details] profile
This happens with all the "widgets", not only folderview.
"Especially for the background wouldn't it be enough to pre-genarate it and use a scaled instance of it." that would complete defeat the entire point of using SVGs, and at that point we may as well just use PNGs for everything. we _used_ to just scale the entire widget during resize (4.0 and 4.1) and it looked utterly HORRIBLE. "Once QT could use XRender to do scaling, all those operations could be hw-accelerated." i doubt that's how it would work out in practice, actually. in any case, possible solutions might include: * speeding up rendering of SVGs to pixmaps * doing fewer updates of the widget during resizes (e.g. compressing resize events) * pre-rendering the background at different sizes from the SVG (though that would take additional disk space and would move the problem to being disk i/o, and it would still be pushing a bunch of pixmaps around, though)
Using KDE SC 4.3.4, the resizing of the plasmoids is quite fluid. I am using Qt 4.5.3, the Xorg Debian package 1:7.4+4, with an Intel 945GM graphic card. Is the problem still existing in the latest version of the softwares?
This still happens for me, with kde-4.3.4 Add a folderview to the desktop and resize it. As soon as it approaches a size of ~1000x1000 pixels the resize-animation gets stuttering and feels slow and unresponsive. I'll do some profiling if've some spare time, but I guess its inefficient painting algorythms (QT doesn't even use system gradients, or picture transformations!)
4.2.2 still present. Simply take a folderview and resize it to screen-size - the animation barely reaches 2-3fps, wasting tons of time in SVG rasterization and poorly coded QT effects trashing the X server with readbacks. - Clemens
4.4.2 - still horrible slow resizing. Because my Notebook broke I borrowed a Pentium-M based one, which features a larger display - resizing a simple FolderView plasmoid is in the range of 1-3fps. Profiling reveals most of the time is spent in SVG rendering inside QT. Probably KDE should re-consider using SVG for interactive rendering?
4.4.85 - still slow. Especially horrible on older computers with large screen.
4.5.5 - still slow. If I resize e.g. a folder-view plasmoid on my desktop (1920x1200) I get no more than 2-3fps.
it's gotten better with each release, and Qt 4.8 brings some more incremental improvements. there is only so much we can improve it further with QGraphicsScene; we hope to get more improvements with the move to QML that we're in the midst of. unfortunately, this report has no metric for "this is now done" which is a requirement for a useful bug. we do care about performance and improve it from release to release, however :) (on my laptop attached to a 1920x1080 screen, it resizes with quite reasonable speed even at near full screen sizes)
I'll try out a live-cd on my laptop and report back.