A Performance Overhaul Of KDE's KWin
Phoronix: A Performance Overhaul Of KDE's KWin
Martin Gräßlin has successfully boosted the performance of KDE's KWin for the upcoming 4.7.2 point release and more so for the KDE SC 4.8 release. This is an attempt to make the KWin compositing window manager handle rendering at sixty frames per second, which it hasn't been able to scale to that frame-rate due to deficiencies in the project's code-paths...
KDE would be totally lost without Martin. What an amazing guy.
I get fantastic FPS with Mutter and Gnome3 on my Intel 965GM, using SNA and very recent kernel and mesa from git. Everything is smooth It's as smooth as Mac OS X. I don't know how they do it, but I've never used a more smooth compositor than mutter/clutter.
I know KWin can do it too, but they'll need to either cut down on the number / complexity of the effects, or keep optimizing.
All very nice... but I imagine that full screen videos/opengl play like crap. (mutter does not unredirect full screen apps).
Originally Posted by allquixotic
KWin has issues with unredirecting as well (the screen flickers when something appears over the fullscreen app), so they have disabled that option by default now.
Unfortunately, Martin says this simple optimization won't make it in 4.7 because it counts as a feature, for some reason. With draconian policies like that, it's a wonder KDE gets anywhere.
And whenever I was complaining about KWin being slow for me, I was labeled a troll or liar. In your faces, hypocrites.
And hoorey for Martin; at least the problem will be fixed, at last.
There are already enough people complaining that KDE is too buggy. Allowing massive changes to point releases would be a disaster.
Originally Posted by siride
Looks like the quick and dirty fix checked in to 4.7.2 avoids a vector copy which was being done over and over again by just using the reference. The "real" fix in 4.8 will adjust the whole way that code works.
I think the consequences of unredirecting are too much of an engineering headache to make it worth the performance gain. When you unredirect a window, you either have to disable compositing entirely, or else figure out a way to work around the limitations of unredirecting. For instance, what do you do if a modal dialog window pops up in front of the fullscreen app? Plenty of "fullscreen" applications would want this; for instance, for generating a dropdown menu in many widget toolkits, they create a new XWindow.
No. Unredirection gives me headaches just thinking about it. The point of a compositor is that everything is redirected. What we need is to work on reducing the overhead of the compositor, both on the driver side and the compositor side. If the redirection can be made cheaper, we'll be in good shape.
Look at how Windows handles it. Their equivalent of "redirection" in Aero is essentially uninterrupted, even when playing a full-screen 3d game. But the overhead isn't enough that you would get noticeably higher FPS if you disable Aero. So most games just let Aero run. There's too much flickering and flashing when enabling/disabling the compositor anyway (and that goes for Windows and Linux desktops alike).
Unredirection is a kludge that works around a present-day perceived performance hit by going back to the old days of non-redirected windows. Mixing and matching redirected and unredirected windows is nasty. And if we'd just give our software and hardware some time to mature, the performance issue will disappear, and we'll look back in hindsight and wonder why we cared about that unredirection crap anyway, and wish we could eliminate it.
In the not-too-distant future, R900-class hardware will be as old as R300 looks today. Let's plan for that by figuring out a way to make everybody happy with redirection, rather than trying to workaround a bottleneck in present-day hardware and software paths.
It does in the 3.2 dev branch http://www.phoronix.com/scan.php?pag...item&px=OTg1Mg
Originally Posted by _txf_
Tags for this Thread