Linked by Thom Holwerda on Tue 1st Nov 2011 21:31 UTC, submitted by Z_God
KDE Disappointed with KDE 4's performance and other shortcomings, Timothy Pearson continued KDE 3.5 development under the name Trinity. Today the first third major update of the Trinity Desktop Environment is released, providing an alternative upgrade path for KDE users who do not feel comfortable with KDE 4.
Permalink for comment 495229
To read all comments associated with this story, please click here.
RE: ...
by lemur2 on Tue 1st Nov 2011 23:50 UTC in reply to "..."
Member since:

I recently tried KDE 4.7 and I must say that it doesn't crash anymore on me this is a great advance, there are still some problems, mainly KWin. KWin is fat and slow, it needs to be optimized a lot, the defaults are bad, I had to turn the blur and other stuff to make it more usable and still it wasn't all that great.

There a couple of recent performance improvements for kwin effects which were due for inclusion only at KDE 4.7.2 and 4.8.

"Alex’s complaints got me wondering why we are not able to render 60 frames/second. Each frame should only take 16.67 msec and knowing that our repaint loop is fine, I could not imagine how a frame could take longer to render than the 16.67 msec. Knowing the KWin’s source code pretty well I suspected two parts of the repaint loop to be slow: the method which actually renders each window and our effect chain. The effect chain calls each effect in turn to transform windows. I had an idea to improve the effect chain for quite some time by calling only the currently active effects. That is currently each effect checks first whether it is active and just does nothing. So you basically call all effects again and again and nothing is actually performed except waisting cycles on checking whether it should do nothing (some effects are heavy there).

Of course I do not just optimize without checking if the code needs to be optimized, so I did an analysis of callgrind output and I was surprised.The effect chain was way more heavy than expected. In fact it’s so heavy that the paint method doesn’t matter in comparison. A deeper analysis of the code showed that there is a small bug, which we will fix in 4.7.2 (too late for 4.7.1), so that we can give the benefits as fast as possible to our users. But the real optimization by only calling the active effects will hit only 4.8. After that change the effect chain is no longer visible in the hot pathes of KWin. Also the change immediatelly helped to identify some expensive checks in some effects which are now ensured that they are not called in each frame (unless the effect is active)."

Apparently it affects only some systems, because kwin has been rendering at 60 frames per second for quite some time now on a number of my quite modest machines.

Anyway, the kwin optimizations of which you speak already exist, the first of them has been included in the most recent KDE rlease (4.7.2), and others a due to follow in the next point releases.

Reply Parent Score: 4