Skip to content

On KWin's composite performance, part II.

Sunday, 24 August 2008  |  lubos lunak

I got a bit bored this weekend (ok, ok, I had to do a lot of cleaning and so and needed an excuse) and had a look at two performance related things in KWin. First was fixing the CPU usage problem caused by using vsync, now that Thiago found out why I couldn't reproduce it (I build Qt without Glib support, it just messes the backtraces up). Interestingly it was code that was supposed to save CPU that by mistake caused the increased CPU usage. Oh well. Second improvement is unredirecting fullscreen windows - that is, if a fullscreen window is not covered by something else, such as a game or a movie, that window is excluded from compositing and allowed to draw normally. This lets it draw at the full speed and should also help with avoiding tearing. The simplest way to see this is to maximize a glxgears window and then compare its reported number of frames to also making it fullscreen using Alt+F3/Advanced/Fullscreen. I could post a video, but it would look quite similarly to the previous performance joke. This one is for real though. The small downside of unredirecting a window is that it no longer has a preview e.g. in Alt+Tab (could be handled with some more code, but not a very high priority now, unless somebody else feels like doing that or I get bored some other weekend).

This should mean that right now KWin's performance should generally match that of Compiz. Maybe a little difference here or there (I haven't really yet optimized the common paths that much), but I'm currently not aware of anything that should make a big difference. Some time back I even improved the so-called 'keep window thumbnails' functionality, which with the 'shown windows' option should match in practice what Compiz gets with viewports, i.e. previews for windows on inactive virtual desktops and fast virtual desktop switching.

So I hope people now won't have to write many rants about this or even complain about KWin to Compiz people (well, I guess I can see that as some kind of payback for them calling an internal Compiz utility 'kde-window-decorator' and making us get a load of bugreports about it :) ). Those screenshot just show increased CPU usage, i.e. the vsync bug, nothing interesting about them, except that you can't see the without logging in (really interesting that forum implementation, I mean, what kind of an idiot puts captcha on a search form?). I hope that person could be satisfied now. And, as for the KWin design flaws mentioned in the reply, I've already taken care of that: Me (notice the evil look): You screwed up KWin's design!!!!! Matthias: Oops, sorry, did I?

No, just kidding. KWin's design is still about the same like in KDE2.0, and, apparently, it still just works. I can't see a problem with not having been designed from the group up for compositing, something that nobody even thought about at that time, yet getting there when the time comes. I, on the other hand, think it may be interesting to watch how something that was designed that way tries to work also without. Especially if somebody at Novell decides that I get to watch that very closely (may happen, isn't life fun?). Don't think I'm bashing Compiz however, as it is a great CM, it just has a little while to go ;) (or, to put it differently, it is never a very good idea to talk about work of others and not know much about it... ).