After some raving blogs about how memory-efficient and fast KDE 4 is, I decided to test something myself.
I felt there are regressions in drawing performance in some apps, and I tried to quantify that a little bit. Of course, entirely unscientific, but the patern should be clear... For those who wonder, as far as I can tell, debugging is off in my build and my hardware is pretty nice - a 2.4 ghz dualcore AMD with 3 GB ram. It was all done in a KDE3 environment.
Procedure:
1. Start Ksysguard (the kde 4 version of course, as it looks much cooler), and minimize.
2. Do some Stuff.
3. Use Ksnapshot on Ksysguard ;-)
I tried Konqueror and it's autoscrolling feature (shift-down-arrow) and Gwenview (drag a big picture around). Here the results:
As you can see, Konqi in KDE 3 uses barely any CPU over the baseline when autoscrolling. The KDE 4 version, on the other hand uses quite some CPU.
Here I pan (is that the right word?) the image around. As you see, Gwenview 4 easily uses 100% cpu (one core) and is visually very laggy, too. The KDE 3 version looks entirely smooth, and indeed doesn't get to use a cpu core fully ever. Again, a performance regression.
Well, what can I say. There sure is still a lot to optimize, and maybe these issues can be fixed very easily. After the positive blogs about memory usage I became rather sceptical - I mean, with so much code changed and so many new features - could KDE 4 really be that much faster? Now I didn't test memory usage, which might very well indeed be much better - but at least these two apps got slower in the rendering/painting department, so here's the balance ;-)
Other remarks: yes, ksysguard uses 20% cpu when drawing 4 sensors and put full-screen. Awful indeed, but the KDE 3 version doesn't do much better, and minimized the cpu usage is reduced to almost nothing. Besides, it looks damn sexy, doesn't it?
The big spikes marked 'xplanet' - you guessed it, it's xplanet, which updates my desktop picture every 5 minutes using some pretty pretty big planetary pictures - so it takes a while.
One more thing. I played with the colors in Oxygen again. And in my humble opinion (those who know me know I'm rarely humble, but whatever) Oxygen rocks, it really does. It is one of those rare themes which looks amazingly good in a wide variety of colorschemes. Despite the fact there are a few unfinished things (but that's true for almost all of KDE 4) it is imho the best theme ever made. Original (it looks as much as Vista or Mac OS X as those look like Windows 95) and brilliantly smooth.
The best thing about Oxygen is some quality it shares with Dolphin: it grows on you. At first, Dolphin didn't appeal to me - I love konqi as a filemanager. And I wasn't impressed with Oxygen much either, I normally prefer very glossy themes like liquid or Polyester. Oxygen, I thought, was kind'a boring.
After using it for a while, I've grown very dissatisfied with any theme on KDE 3 - I find Domino, one of the most modern KDE 3 themes, bearable, but that's about it. And I find myself using Dolphin more and more, to the point that I installed the KDE 3 version on my main system...
So, to those bashing Oxygen, Dolphin and Kickoff - wait until you've used it for a while. You'll probably discover you don't wanna go back...
I'm not sure if this is related, but I also have an issue where, whenever I open a menu, a rectangle of static on black shows in its place before it's drawn. Rather distracting.
ReplyDeleteYou don't say anything about your graphics card, nor the drivers you use.
ReplyDeleteThat makes this kind of useless, imho.
I think scrolling a web page in konqy and panning an image may be the same problem.
ReplyDeleteIn both cases big "images" (pixmaps ?, whatever) are drawn by the application and then have to be transferred to the xserver (I think).
I think here the double buffering of Qt4 might be a problem here. I mean, with Qt3 (probably) the xlib functions were used to draw text, rectangles etc. for the web page. Now with the double buffering (I think) text and rectangles are drawn by Qt functions into a buffer, and then this buffer is transferred as one image (or pixmap...) to the x server, which would be much more data to be transferred.
In case I am right, how does Qt4 perform over remote X ?
Alex (neundorf (AT) kde.org)
Well, Martin, as you can imagine, I didn't change graphics card and drivers in between the tests, so on a Geforce6600 256mb with proprietary NVIDIA driver ... KDE4 does worse than KDE3.
ReplyDelete@Alex: I can't test remote X here, but it sounds like a good answer ;-)
Having the ability to disable the doublebuffering globally in Qt4 would be a good thing, as it's supposed to use a lot of memory, and if I understood the issue correctly it's also not needed when using Compositing...
You said this was all done in a KDE3 environemtn, so what about doing the same test i9n KDE4?
ReplyDeleteIllissius: with which chipset are you experincing the issue? I have the very same behaviour on a radeon 9200 (R200) with radeon opensource driver. If it's the same I could open a specific bug
ReplyDeleteAlex: The behaviour you describe is what double-buffering prevents, afaik.
ReplyDeletejospoortvliet: I don't know about the support in the nvidia drivers, but have you tried using EXA instead?
@illissius and @vide: I have the same problem. Using kde4 on a HP nx7400 notebook with a i945 graphic chip.
ReplyDelete@jospoortvliet: it would be nice if somebody who really knows could acknowledge this.
ReplyDeleteSet the env var QT_ONSCREEN_PAINT to true before starting a Qt4 app, then you'll see how it behaves without double buffering. It feels really different.
Qt4 designer shows such performance problems quite good (i.e. resizing it or dragging splitter widgets)
Alex
@alex:
ReplyDeleteexport QT_ONSCREEN_PAINT=1 does make a difference - but only in the negative sense. It introduces heavy flashing and visual artifacts, yet Gwenview still pans incredibly slow. And Konqi still uses a huge amount of CPU.
So if that setting is supposed to solve problems due to doublebuffering, then doublebuffering isn't the reason Gwenview and Konqi are slow ;-)
vide: Intel GMA950
ReplyDelete@jospoortvliet: well, I said "it feels really different", I didn't say "it feels much better". And no, it's not supposed to fix any eventual double buffering problems. Actually I don't know if there are any double buffering problems, that's why there were so many "I think", "probably" etc. in my comment.
ReplyDeleteI also get a lot of flickering if I enable that variable, but it behaves definitely different. While with double buffering there is a (relatively) big delay and then it appears instantly, without it stuff starts appearing much sooner but takes (mostly) longer until it is done.
I wonder a bit why it behaves without DB so much worse than Qt3. maybe because Qt3 was optimized to work good without DB, whereas Qt4 is not optimized to work fast without DB (because DB should be used).
After all the for both modes the drawing should happen basically the same way, i.e. the order and the type of drawing functions (draw a line, text, etc.) should be the same, just that with DB it uses some Qt functions on a buffer and after that transfers it to the server, without DB the appropriate Xlib functions should be called.
Maybe you can get an answer from somebody who actually knows this
in detail ?
There is also still the kde-optimize list, which didn't have traffic since some months.
Alex
These kind of issues is why I personally am extremely sceptical against KDE 4. It's a huge mistake publishing this as being the new next-generation desktop for users. It is not stable enough and still has too many problems. People will be disappointed, because they expect KDE 4 to be a great release. It seems like it will take until at least KDE 4.1 until all those expectations can be fulfilled.
ReplyDeleteDebug build? Or release build? Don't forget that makes a huge difference for performances...
ReplyDeleteagree, oxygen is gorgeous!
ReplyDeleteI also compared scrolling konquerer (kde3) with dolphin (kde4) with an athlon-xp-1600 and old radeon-graphics-card. the scrolling in dolphin is really lagging, really unusable.
ReplyDelete@illisius and others: afaik, this is/was a bug in the oxygen style. i'm personally not seeing it anymore, though i used to all the time. perhaps it's been fixed in recent svn commits. (probably has)
ReplyDelete@jos: is this with kwin compositing turned on? if so, could you try the same with composite off? just measuring total cpu makes it hard to know exactly what is causing which problems.
@Aaron: a KDE 3 environment, complete without a compositing windowmanager ;-)
ReplyDeleteIn other words, tests were with plain old Kwin from KDE 3.
There seems to be a little bug in the scroll area, where at some point the whole area gets unnecessary updated when scrolling (instead the newly exposed area only). You will see it if you increase slowly the scrolling speed for e.g. in dolphin. I mentioned this in a bug report to TT yesterday, let's hope they can optimize it a bit further.
ReplyDelete