A Line in the Sand
First, I'd like to discuss what constitutes an acceptable experience with KDE 4. There will always be some things, like desktop effects used in KWin, Plasma and KRunner, that simply require a decent video card. However, all of these programs should be runnable without those effects and retain an acceptable user experience even on older (within reason; e.g. not 15 years old ;) hardware. Good news is that they do, given decently supported hardware.
It is not acceptable if KDE 4 feels slower than KDE 3, and it is not acceptable if KDE 4 requires brand new hardware. At the same time, if the drivers for older hardware are simply not up to the task and those drivers aren't updated ... there's not much we can do about it and that hardware, which would otherwise be capable of better things, shouldn't be part of our target. It's also absolutely acceptable if certain features only work if the hardware can support them; this is mostly applicable to features reliant on more advanced graphics techniques.
I've seen the KDE 4 Plasma workspace as well as KDE 4 apps run smoothly on devices as small as the N810, on netbooks like the EEE PC, on older desktops and on new bling-bling laptops. The code base does scale well, but unfortunately it doesn't scale well everywhere ... yet. What gives?
Troubleshooting 101: Note the Variances
Have you ever noticed in these discussions how some people say KDE 4.x is "totally unusably slow" for them while others say the performance is just grand? Others say "it sucks!" and then tweak their graphics system (x.org, driver versions, driver config, kernel modules ...) and say "wow, waaay better!"?
Even if we normalize for differing expectations (one woman's "fast enough" might be another's "unnaceptable), we're still left with variance here even with the same code base. This is a critical observation, because it means that we can search for these variances and then work backwards from them towards possible solutions.
So let's go through a handful of these variances ...
Build Time Optimizations
There are some code paths which are god awful slow in a full debug build of some parts of KDE 4. The code that causes the slowness is great for debugging and troubleshooting, but can suck for performance. It's really hard to do proper "seat of your pants" performance measurements unless we're dealing with debug builds. This has bitten me in the past, and I know it's bitten others as well.
It's one of those occasional and unfortunate trade-offs: a bit of the user experience is diminished by running a full debug build that's better for development.
Measuring Performance
This is also why "seat of your pants" performance measurements are not overly useful. What do I mean by "seat of your pants performance measurements"? Here are some examples: "I ran this program and it just feels slow"; "When I scroll in Konqueror using the arrows keys, scrolling seems really jerky." These observations can be useful as starting points: they let us know what might be actually useful to work on as far as improving the user's experience is.
But to really know what is going on we need to profile the application. Often it's not what you think, and profiling can also let you know when it's debug code that's causing the problem without having to keep a separate release build around. So don't jump to performance conclusions based on "seat of your pants" observations; use them only as clues for where to start.
Valgrind and KCachegrind make profiling stupidly simple and very powerful. Even I can do it. ;)
Areas of Performance
Ok, this is probably stupidly obvious for many people, but there are several parts of the computer that can impact performance negatively.
Main memory (RAM) usage can be one: if main memory fills up for whatever reason (applications using it legitimately, applications leaking, etc) then things tend to fall back to disk swap which is painfully slow; worse, file caching is lost and all file access hits disk, also painfully slow.
CPU over-utilization can also degrade performance (to state the obvoius ;). Unlike memory usage, this usually means one of three things: the application is simply trying to do things that CPU is not capable of (rare these days, outside of truly high end applications); the algorithms used in the application are either buggy or plain inappropriate for the task and should be fixed of changed completely (most likely); there is something happening in software that should be happening in hardware (this is a typical problem with graphics). Again, profile really helps here because it's often next to impossible tell which it is without peering into the runtime execution paths. Sometimes something you think is happening on the graphics hardware isn't because of unexpected behavior in the toolkit or other pieces of software being used, for instance.
GPU under-utilization can degrade painting performance. This is probably one of our biggest weak points right now. Unlike in immersive 3D games which we expect to pin our CPU and/or GPU to 100% to get us the best framerates possible, this is a taboo in productivity applications. But to get a smooth experience without hoggin the CPU, hardware acceleration is required. Doing graphics on the CPU can all too quickly eat up most of the cycles available leaving apps little room to do actual work.
The State of the Art Event Horizon Problem
One of the problems we are facing in KDE 4 right now is that we're trying to deliver a modern user experience. We aren't defining "modern" by "what $OTHER_COMPANY is doing today" but rather by "what matches with our vision of kick ass". There's certainly inspiration and lessons we draw here and there from various companies and other FOSS projects ... but we aren't limiting ourselves to that.
In the process of creating this modern user experience, we are doing things that just haven't been down on the FOSS desktop arena, or in some cases any production user interface arena. This pushes into areas we haven't gone before.
The Plasma performance issues are a great example of that. There have been a number of graphics drivers out there that simply have issues with applications that use translucency (sometimes referred to as "argb visuals"). They work fine with compositing window managers, but that's because they use translucency in a rather different way. x.org itself has/had numerous straight out bugs when it came to argb visuals. I demo'd these issues for various x.org developers and every single one of them I showed it to were surprised about the problems.
Why is this? Well, when Plasma came onto the scene there weren't any other production apps doing to the graphics stack in x.org what Plasma was. Untested code equals unfound bugs and unknown performance boundaries.
Plasma isn't the only area we're running into this kind of "event horizon" issue.
x.org and Graphics, or How I Hope It Won't Do Graphics In the Future
We also deal with things right now like XRender which is supposed to be a way to accelerate certain common rendering activities. Things like text rendering, which is used a lot in applications like web browsers, mail readers, word processors, etc. The probem with XRender is that it is designed in a way that doesn't map all that wonderfully to how graphics hardware tends to work. So while there is decent acceleration for some or most of XRender in some graphics drivers, it's abismal on others and never really reaches the full potential we should be seeing due to design issues.
This isn't the only issue in x.org, but it sort of highlights one of the big ones: x.org has some pretty big issues when it comes to doing graphics. That's why nVidia includes in their driver a rewrite of pretty much every bit of x.org that touches graphics. This in turn causes havoc of a new variety: does nVidia's twinview map nicely to xrandr/xinerama or does it get screwed up? (Answer: often the latter.) Issues that get addressed in x.org need to also be fixed in the nVidia driver if they exist there too, and vice versa. It's just not pretty.
This is one of the primary reasons why I'm very excited about Gallium3D: it's a modern graphic stack done by graphics gurus that is designed for the real world of hardware. I've seen it action, and it's impressive.
If the FOSS desktop world is smart, the future of x.org will be as an application windowing protocol (window management, for instance) and an event system. All hardware support will move into kernel drivers where they belong (this is already happening / happened), and graphics itself will be handled by Gallium3D or something like it.
In the meantime, we're a bit stuck working around and within the limitations of today's x.org reality.
Qt4: Room For Improvement
Qt4 itself has room for improvement. There are graphics paths that do things in software that should be done either smarter in software or in hardware. A proper OpenGL paint engine for Qt4 woudl also rock the house considerably. Note that Qt works very well with OpenGL-in-a-widget, but that's not the same thing. I'm talking about all QPainter operations happening in hardware where available, which is very nearly everywhere these days. Even today's mobile devices can manage this, something driven largely by power usage. We don't have that yet, but when we do things will be nicer.
Before that happens, though, there is still lots of room for improvement in Qt4. I've talked with many of the engineers at Qt Software about these things and they have been working a lot on performance in Qt 4.3 and 4.4 with even more to come in 4.5. Performance is not an easy (or fun) issue, and with all the new code and approaches taken in Qt4 it is taking time to really get it slick-as-snot fast.
This isn't to say that it's slow right now, mind you. It's rather impressive right now given all the features it supports, but it's just not as fast as it could be. Thankfully this is a knwon issue and one that Qt Software people care about enough to actually put substantial and continuous effort into. As these efforts come to fruition, KDE 4 will also "magically" improve in performance.
And Where is KDE's Responsibility In All This?
So I've picked on the whole stack underneath KDE 4 by this point in the blog entry. I don't want to give the false impression, however, that KDE has no culpability in the current situation.
There are few truths to keep in mind that impacts KDE 4's performance:
- For a lot of us, this is the first time we've used these new techniques and we have more to learn about how to use them best.
- There is a lot of very new code in KDE 4, and new code means both new bugs as well as new unoptimized paths.
- We can work around some limitations lower in the stack better than we do now, though sometimes we need to patient and let the stack catch up with us.
Just as with Qt4, and perhaps even more so in places, we have a good amount of optimization work ahead of us. We works for years on optimizing KDE 3 in various ways, and while we carry much of this work with us into KDE 4 we also have huge new sections of code to repeat this effort on.
Bringing the KDE 4 codebase to maturation will help improve performance, and that's something that can only be accomplished over time. Thankfully, we're doing just that. How fast are we doing that? That's something we can only measure in performance deltas between releases.
So ... what does all this mean?!
It means that there is work that needs to be done at every level in the stack. We've taken the FOSS desktop to a whole new level with KDE 4, and we're pushing it even further with each subsequent release. By setting that bar higher than it has been in the past, we've created new areas of work for ourselves.
But because that work is spread out across the stack, it means that there will be vast variance in user experience right now: something as small as a driver revision upgrade can make all the difference in some cases. It also means that we can't just look at the user experience and point a finger at any one thing, e.g. "KDE 4 is slow, so fix it KDE team!" Profiling is critical, so we can pinpoint whether the problem exists in KDE code, Qt code, x.org, drivers .. elsewhere? Then we need to figure out whether it's best to wait for the stack to catch up (and communicate these pain points to the owners of those parts of the stack) or if it is better to change something in KDE's code itself.
Also remember that there are any number of possible issues: text rendering speed, image manipulation performance, graphics in software vs hardware ...
If that sounds like it's not an easy problem, that's because it's not. It's a wicked problem, one with no single cause and no single solution. We need to track down these issues one by one, by profiling code and exercising the software on different hardware/software configurations, and improve them. It will be an incremental process, but it's doable.
It Works For Me
If you think that I'm displaying a lot or maybe even too much confidence, here's why I have that confidence:
Right now, KDE 4 flies on my laptop, and it's hardly a screamer by today's standards. So I know it's possible for KDE 4 to perform very well.
I also keep close tabs on work going on elsewhere in the stack and am very happy with the directionality of it. Work is being done in pretty well all the areas we need work to be done in to improve the event horizon issues.
I wish I could wave a magic wand and make KDE 4 work like a speed demon for everyone, but that's just not realistic right now. At least I know there is light at the end of this tunnel, and that things work well for a large number of people already as it is.
The alternative would be turn around now and go back to a 1990s era desktop as we had in KDE 3. It was solid and stable, but had an extremely limited future for the general user base. Going back to something that has acceptable performance today for everyone but which is a dead end tomorrow isn't really an option, especially when we can get what we have now working as well or better than what we had. We should also avoid rose coloured glasses and remember that performance in KDE 3.0 also sucked with noticeable improvements with each release; the same is happening with KDE 4.
So it's not a perfect world, but one that's getting incrementally better. I doubt that's news to anyone, and I hope that the above helps to at least add some substance to what is often a rather shallow discussion.
38 comments:
Of the things you have said, i would really like a more streamlined, plug&play X.org. updating xorg-apps would also be cool :)
The fact that KDE 3 did indeed get faster over time is probably the most reassuring thing.
And KDE3 didn't even have pressure from any N810s or EeePCs to make things faster. I have a feeling the mobile market will result in a faster desktop for everyone.
The start of solving many problems is in measurements - and I'm quite sure this is one of them. I imagine a (large) number of dedicated tests in a KDE module that test basic operations in a number of different applications and usage domains. One test that simulates loading a page in Konqueror and scrolling from top to bottom, another one that goes backward and forward in history in Dolphin, a third one that repaints a constantly changing list of items and so on - basically like a regression test suite, but only focused on performance. Once you have all the measurements (and you don't have to have them all at once, you could gradually add them to cover more and more of the code base), you'd start generating nice graphs of the time it takes to run each test. Graphs like that show performance regressions immediately and - as a bonus - should attract people who want to get the lines in the graph to go in the right direction :). It's like Intel did with PowerTOP: people started to focus more and more on for instance inefficient polling interfaces once their code showed up as a problem in that program.
(I fear I have to add the lame excuse of 'no time to do it myself' - but would be really glad if it existed!)
I think the most important thing is that (in those areas where KDE4 does everything right but the drivers or x.org are making trouble) it will push the boundaries and force people like the Nvidia developers to do their work.
On the other hand I'm sometimes wondering why things that used to work are suddenly slow. One example is Beryl vs. Compiz. Beryl ran much smoother for me that Compiz ever did and nobody could tell me why. After almost a year of trying I reverted to Beryl. I sincerely hope this is not the way it will be with KDE4...
KDE4 is slower than KDE3 - there is no argument about that. But big part is "appearance of slowness". For example: when I initiate action in KDE3 application is starting to do something immediately. In KDE4 there is noticeable delay. Complete action with all redraws, item displaying, etc. takes only sligthly more in KDE4 but this initial delay is giving overall impression of KDE4 slowness.
To be more precise: displaying of directories in Dolphin. After you click to open folder there is short waiting, open blank window, long waiting and all files are displayed almost immediately. In Konqueror from KDE3 files were displayed partially giving "progress bar" impression.
Note: the only parts of KDE4 which are *really* slow are where SVG and Plasma are involved.
@jonathan: couldn't agree more. measuring with valgrind (something an advanced user can easily do) and then sending the output files so we can examine with kcachegrind would be terrific.
@tobias: "it will push the boundaries and force people like the Nvidia developers to do their work."
yep... =)
"On the other hand I'm sometimes wondering why things that used to work are suddenly slow. One example is Beryl vs. Compiz. Beryl ran much smoother for me that Compiz ever did and nobody could tell me why. After almost a year of trying I reverted to Beryl."
the reasons for these kinds of differences are often as complicated as the issues we're facing in kde4. there are rarely simple answers to these questions these days: the software is complex enough now that explanations are lengthy and often very technical. =/
"I sincerely hope this is not the way it will be with KDE4..."
i can't predict the future nor can i guarantee no future regressions, obviously, but we tend to work towards globally greater performance over the lifespan of a stable release in KDE. it doesn't seem to be any different with KDE4.
@mikmach: "After you click to open folder there is short waiting, open blank window, long waiting and all files are displayed almost immediately."
there has been significant work on performance in dolphin, and it does indeed load directories progressively. there is still room for improvement, but it's a lot better than it was in 4.0 or even 4.1.
"the only parts of KDE4 which are *really* slow are where SVG and Plasma are involved."
for you, perhaps. for others they aren't slow at all, and for yet others there are different issues altogether.
this is really the gist of the post: it's a more complicated world that doesn't afford such blanket statements.
I know that KDE4 is not slow on developers machines, otherwise they would NOT use it (unless it is actually broken and they can fix it) ;-)
On my nVidia machine, the KDE4 will "fly" only if Kwin effects are turned OFF. Why I keep them ON? Because I have already used those and I like them too much. It is now more like asking to go back to KDE3 or live without Plasma, so those are important.
But I have only problems with nVidia cards, AMD cards just flyes and I know that there is lots of possibilities for KDE4.
So What I can do? Only wait nVidia coming with their Fix. Do I blame KDE developers? No way... unless the problems are on their code and not on nVidia but we know the case...
I like that someone can rise the cat on the table to discuss. The official discussion can be on mailinglists but on blogs, it is nice because I dont usually follow mailinglists. But blogs just tends to bring problems for developers when people is whining about things what is not developers fault...
I've always been a Gnome guy myself, but KDE 4 shows a lot of promise, and I keep going back to it in various distros. At this point mostly to try it out for fun, but each time I'm more convinced that something big is about to happen. This blog, as well as others, keeps me reassured that a lot of effort is put into making it all a great experience. It may take a while and a few more 4.XX versions, but eventually I'm sure I'll make the switch to KDE permanently. Thanks a lot for all the work done so far and keep us posted on what's going on!
Anders, Stockholm
What KDE4 needs is to be the best desktop in a couple of things now, to give users something to love. If performance can't be one of these let's work more in usability, data portability or external apps integration, some kind of Web 2.0 objectives.
Mark my words, in term of graphics, Qt 4.5 will fly! :-)
in KDE team for speed improvements, I trux ;)
in KDE team for speed improvements, I trux ;)
I am an E17 enthusiast and any desktop revolution enthusiast. To me, right now, KDE4 (4.1.1) wins my heart over GNOME + Compiz. The design can make my day productivity increases. I have the illusion that using KDE4 I have bigger and wider screen, which apparently provide good mood. The real problem to me is the Xorg keep crashing after few days of my PC uptime.
When between KDE 4.1.1 and KDE 4.1.0, I found out *significant* stability improvement in KDE4 (using Debian Experimental), especially in kwin composite effect. So, I agree to you that this KDE4 will evolve and stabilize more.
KDE4 has no performance issue with kwin effects turned off.
If I turn kwin desktop effects on, then the performance is really horrible, it is like running recent applications on 200MHz Pentium2.
This is obviously not an nvidia issue, since my intel 915 integrated card also suffered from that.
The same computer runs gnome+compiz and kde3+compiz without any performance problem. So we know we don't need a very high-performance video card for compiz.
What is the problem? may be xorg, kde4, qt4, but I definitely do not think it lies in the driver.
@pansz: i guess you didn't quite get the point of the blog entry, but as i said to mikmach earlier: "for you, perhaps. for others they aren't slow at all, and for yet others there are different issues altogether."
kwin's composite effects are less than 1/3rd the age of compiz with a lot fewer people having worked on it as well. that's the main issue in the case of kwin's effects. lots of improvements have been made in 4.1 as well as in trunk/ (which will become 4.2). for many people kwin coposite already runs well, but it's not what it could be.
on the flip side, many people do have performance issues with things other than kwin composite, so your blanket statement isn't accurate there either.
it does go to show how complicated it all is.
@the rest of the people saying positive things: thanks, and we're working hard not to disappoint =)
@ariya: i can't wait for 4.5; getting some benchmarks and some descriptions of the improvements out there in the blogosphere would be great. =)
kde 4 became my primary desktop a few weeks before the 4.1 release and I am very satisfied with the experience, composite, nvidia card, and all. There is only one app I turn composite off for.. I wouldn't mind the ability to blacklist composite for that app (and have it turn back on after) but until that day there's a nice toggle composite plasmoid that relieves me of finding the configure dialog. I am excited for the future and pleased with the present. keep up the good work.
Here everything works really smoothly also, keep up the good work and THANKS a lot.
http://mireq.linuxos.sk/kde4/kde-4.1.66/kde4_animations.mov
Athlon XP 2500+, Nvidia Geforce 5200
I also have to say KDE4 is slower than KDE3 and there is not even a point on discussing this, 4 have much more technologies and visual than 3. It does run very poorly on my eeePC 701, but some said they run it fine, so maybe it's a distro thing also, but in my case I blame on memory, because KDE4 did run very badly on my Duron 1.6 with the same 512 RAM as the eeePC, so probably upgrading the RAM will bring lots of performance improvements.
That said, there is a lot of room for improvements, as version 4 is still on it's infancy, and I remember well that performance in version 3 was not that good until in .4 version developers started focusing mostly in performance, and only in the .5 release, people where really happy about it.
I believe part of the frustration about speed comes from promises that QT4, that is faster than Qt3 (yes, it is, I've ported some apps and I can testify) would automatically (and some had actually said that fullish thing) make a whole new KDE faster also. This would only happen if KDE4 was a straight port from KDE3, and it is not.
So, maybe we should just keep complaining (yes, it's not nice but developers also must hear the bad side, not only congratulations, and it works) until the issue is fixed for good ;)
Thanks for the article.
Absolutely stellar post, I think you hit all the best points. I've been following KDE, QT, Xorg for a while and have been wondering when the collision would occur.
@Iuri: just complain constructively; that's all i ask =)
@Aaron: Well, I hope I did it this time ;)
Anyway, one solution I see, besides time, is just not using plasma. Try running KDE4 apps inside KDE3 or some lightweight DE like iceWM. SOme apps like dolphin, okular and umbrello are much better than KDE3 counterparts.
As I just want my eeePC to be fast for network, I ran it with KDE3 and Opera :)
But it's fun, running Apache+PHP+MySQL+Quanta+ on it is much lighter than running a KDE4 session :-P
I think some folks are getting hit by nepomuk and strigi running in the background and sucking a fair amount of CPU.
I've got a motherboard based 8200 nVidia gpu running at 1920x1200 which is not a hot combo, if I set up blender, konqueror and firefox, each maximised on it's own desktop, then instantly keyboard switch between them then blender is instant, zero observable repainting, konq (or any KDE4 app) has a barely noticable repaint but firefox is by far and away the worst culprit where I can see the repaint travel down the screen. So,to me, KDE4 apps are pretty damn fast, but not "instant" like a native GL app, but way better than firefox (cairo at fault?).
Blender also starts up noticably faster than any KDE app (at the same window size) and, again, firefox is the slowest. My point is that relative eyeball "gut feel" tests between a native GL app (like blender) and a hog like firefox could provide a simple judgement metric.
Aaron, do you think you could post your valgrind setup? I've tried profiling KDE apps in the past and I just haven't had any luck getting meaningful output. In particular, what cflags are you using? What libraries have you compiled with debug symbols? How do you deal with inlined methods? That'd make a great techbase article!
Thanks for the hard work, KDE4 is great!
I'm using KDE 4 (SVN) for daily use, and it feels great. I have good machine (4gigs ram, and gf 8800gts), but on my older pc it runs great too. All i need is new features. Keep the great work KDE team. ;]
@Dave: I'm pretty sure I've seen a composite-toggle plasmoid somewhere.
@aaron: you'll soon hear what we're doing for 4.5 in few weeks. just keep an eye on labs site...
For me, an X11 desktop should be usable through a remote connection (as it's one of the X11 benefits).
Currently, I'm using KDE 3.5 with FreeNX/NXClient (of NoMachine : http://www.nomachine.com/ ) and it works really fine through a DSL connection. I can browse, read my mails with kmail, work with konsole, chat with Kopete, write this post... It's usable.
After some tests with KDE 4/KDE 4.1, it's not so usable. Of course, I have disabled desktop effect and I have chosen a toolkit style like plastik which is simpler and which doesn't use transparent blending effect. But, it's still slow. I think the problem is linked to Qt 4 which manages text differently than Qt 3. With Qt 3, when I scroll a text area, the scrolling is smooth. With Qt 4, I feel that the text is rendered like an image and the remote X server tries to refresh this image which is slow.
So, have you made some tests with KDE 4 and a remote connection (on a LAN with standard X11 capabilities or with FreeNX for small bandwidths) ?
kde4 rocks! U 2!
It works very well with my vaio, even running effects on an intel 945gm.
But, is true, kde 4.0 wasn't useful, now, kde 4.1 is much better, almost, stable as kde3, mmm, well, maybe not, but it's very stable; and remains some easy problems
The way you represented the post is cool... thanks...
desktop software development
you've been talking about argb visual issues in xorg for almost (or maybe at least) a year...
http://aseigo.blogspot.com/2007/12/argb-visuals.html
how's the progress on xorg side?
is there something better than linux and xorg on which kde4 could run on ? for an optimized end-user desktop?
could the xorg people give us some kind of timeline?
@Mathieu: it's gotten better, some things are fixed, some things aren't. these things take time, but they are improving and hopefully within the next year things will work well across the board.
I agree with your post. I installed KDE 4.1 in Asus eeePC 701. Can't say it flies, but it is very much usable, even with KWin Composite activated.
Kudos for KDE 4 team!
@Aaron J. Seigo: I guess I didn't make my idea clear enough.
Yes kwin is fairly new, it is acceptable that kwin effect had bad performance when showing the fancy effects.
But when the kwin effect is on, the Konqueror and Firefox will have horrible performance when scrolling and it is unusable for web browsing. The svg-enhanced kdegames have very poor performance.
Poor performance for screen scroll and svg rendering seems to have nothing to do with kwin effect. But in fact the performance is quite good when kwin effect turned off.
I don't expect the bad-performance of kwin effect would affect my browser scrolling and svg kdegames. That is what I want to point out.
I've been using the Kubuntu version of KDE 4.1. It's got bits missing, Konqueror toolbars don't seem to stay where I want, etc., blah, I'd only recommend it to geeks who enjoy geeking with their daily tools.
But basically I love it and there's no way I'm going back to KDE3. It feels so ... flat.
Looking forward to 4.2 :-)
(Oh, no performance problems - HP Compaq 6710b laptop, Intel everything. Sometimes the desktop forgets I have a keyboard o_0 I suppose I should get to bug-reporting ...)
just an note: kde4 "felt sluggish" until I came across this blog post http://blog.nixternal.com/2007.12.30/intel-945-video-hint/ ...
the suggestions doubled my fps with glxgears and kde4 practically zips!
Hi Aaron,
Thanks all for KDE 4, this is really impressive and is a good starting point.
For my computer, which is running Kubuntu 8.10 (KDE 4.1.2) and a GeForce 7900GS with NVidia 177.80 driver, what I can say is that KWin composite effects really rock. Actually they're much more stable than what Compiz even was, really fast and so on.
I have however two main pains :
- In the session manager if I enable the "restore previous session" mode performance tends to become sluggish and some apps are not restarted correctly such as Mozilla Firefox,
- Performance of KDE4 apps and only them tends to be very sluggish. For example Kontact is extreeemely slow to repaint when switching on it, and Konsole can also be extreeemely slow.
I think there's something wrong with the QT4 painting engine, because if I start non-QT4 apps like Amarok 1.4, any KDE3 app or even any GTK app, the problem does not occur.
Tried to tweak the xorg.conf parameters of my graphic card, but still the same issue.
I know that KDE4 will be great anyway and thanks for all the efforts.
Do you have a published procedure in order to make some profiling ?
"-".
@gojul: Qt4 uses xrender quite extensively right now and falls back to software based rendering in some unfortunate moments.
x.org drivers are getting better at accelerating xrender, though there is a very real cap on that (xrender is inherently not very easy to accelerate and has some design imposed limitations on what can be done with it there)
there's a lot of work happening for Qt 4.5 to address some of these issues, and even more that will come in 4.6.
so with time we'll hopefully get back to super snappy rendering everywhere, regardless of the driver used.
right now it really depends on your x.org graphics driver quality in specific areas and that's an assumption we just can't safely make (sad, but true)
Post a Comment