News from the Wobblyland, part 0.

Zero as when it does not work. And that's sometimes zero fun. There is a plan to enable compositing by default in openSUSE11.1 when possible (just like e.g. Ubuntu already does), so I've been again pondering the idea of enabling KWin's compositing by default in SVN too, just like it was in pre-4.0 times. The "when possible" part is of course the problem. Even openSUSE11.0 is already ready for compositing, assuming proper driver is correctly installed, but there still may be possibly some problems with some setups, and of course upstream KWin does not have the comfort of knowing the underlying stack is configured properly.

KWin is actually quite robust when it comes to handling compositing failures, so if it detects a problem, compositing will just get disabled and KWin will keep going on. And here the "detects a problem" part is the problem. For example if AIGLX is not working, this may result in the only-white-windows-with-shadows bugs, which is caused by the X stack losing window contents somewhere. But, strictly technically speaking, from KWin's point of view everything is working correctly (at least I don't know any error detection of this), it's just that the user does not see what they should see. How is one supposed to detect that? KWin during setup checks X errors, OpenGL errors, various required X/OpenGL functionality, tries to detect driver used, the compiz-manager wrapper script has blacklists and whitelists and whatnot, and yet this all is sometimes not enough.

And then, while thinking about this, I got this absolutely ingenious and yet awfully simple idea (aren't all of them like that?). With compositing, the compositing manager uses Composite extension to get window contents as a pixmap, then binds an OpenGL texture to it and then renders the window to the screen using the texture. So, how about simple trying if this actually works? Trunk KWin now has a compositing selfcheck that creates a very small window with few basic colors painted in it, then it's handled just like described above, and finally the screen contents from the window's position are read back as a pixmap. If it matches the original, good, if not, bad luck, sorry. It's so awfully simple that I'm really surprised nobody has done that yet. With this, many of the other checks are just secondary, just try if it really works, that's it.

That's the theory so far. It works for me, my normal working setup logs "Compositing self-check passed." in the debug output, one setup that until now has been problematic without KWin detecting that now gives "Compositing self-check failed, disabling compositing." (and saves me pressing Shift+Alt+F12 once :)). However, the question is, does it work properly also for everybody else? If somebody has a setup where compositing is broken but current SVN KWin still keeps it enabled, please create a bugreport (also, if somebody for some strange reason happens to be unfortunate enough to have now compositing disabled because of this check even though the system is otherwise capable of it, please complain too).

If there are no problems, KWin will get compositing enabled again by default soon, and I'll consider a 4.1 backport (not enabling by default there though). It would be still nice to find some way to detect whether the performance is sufficient or whether it's too poor for compositing, but there the ingenious simple idea has been eluding me so far (since KWin can't really just measure FPS during startup, for several reasons). Also, there is still the problem of X crashing, drawing artifacts and other nasty problems, but having a hack for that would be a real black magic mastery.

Oh, and BTW, just in case somebody still feels like using something else than KWin in KDE ;), the UI option for switching window managers has been moved to a somewhat more logical place, that is the 'Default applications' control module.