!Rant: Desktop Effects? Hell, yeah!

Last year I wrote a rather strong blog when I was frustrated, titled Desktop Effects? Never more. In that blog, I was relating one of the side-effects that I had when I switched from KDE 3 to KDE 4. For context, for those who don't want to read the entire blog (and you shouldn't), I finally switched just before KDE 4.1 was released. Until then, I had been running KDE 3 and 4 in alternance, or with some KDE 4 applications inside KDE 3, etc. (and it would be a few more months until I stopped using my last two KDE 3 applications: Amarok and Kontact).

The issue that was driving me crazy was that desktop effects were unusable at that time. First, kwin would use 90% of the CPU. Second, windows would disappear (100% transparent) or turn black. To top it off, one runaway debug message in kio_imap4 ate all of my disk space, driving me over the edge (as far as I know, that issue is still present). Since then, I have also had problems with Kontact / KMail -- every two weeks, more or less, it would forget its account configuration then proceed to delete all my email cache.

This blog now had been long coming: I officially apologise for my words and retract all I said. I have been running desktop effects for months now, without a hitch. What's more, all the issues I mentioned in the blog are fixed (aside from the kio_imap4 debug output), including Konsole's redrawing speed on window resize. Turns out that KWin taking 90% of the CPU when using glib was caused by some code that had been designed to save CPU when using glib...

Also contributed to this the newest NVidia binary drivers. It took a long time, but finally the 180.22 version fixed all issues I had in my workstation (8600GT, TwinView) and in my laptop (8400GM, also running TwinView). All versions prior to it had issues, either causing freezes or showing garbage or with disappearing windows.

Now, it would be a pretty boring blog if it didn't have a plot twist: I have been thinking about writing this blog for over a month now. I was delayed due to travelling (I did OSL-MUC-SFO-PDX-DFW-SAO-REC-SAO-FRA-OSL in 15 days, attended two conferences, visited my parents and two offices). And I was delayed by a bug in Plasma.

Last week, after updating Plasma from Subversion trunk and restarting it, the secondary (right) screen in my dual-screen setup started not repainting completely. The wallpaper was shown only at the top-left corner, leaving the bottom and right not painted. And with desktop effects enabled, this not-painted area got composited with the windows, thus yielding garbage. (Think about it: if you alpha-blend a nice Konsole window with unpainted garbage, you get blended garbage)

So I had to turn off desktop effects. And I felt it would be hypocritical to say I've been using desktop effects while I had it turned off.

Well, if I'm blogging now, it's because it's fixed. And desktop effects are back on. The bug was quite simple and doesn't deserve much attention (r948226 is the fix). What's interesting is what I learnt in the process. Besides, this was a one-week period only, whereas I have been using desktop effects for months now.

Remember: I'm the network guy, who knows the tool classes and maintains D-Bus. I don't have the first clue about painting. What's more, my day job now is about maintaining Powerpoint presentations...

1. First thing I learnt is that Qt Creator can already load CMake-based projects quite fine;
2. To load a CMake project, Qt Creator requires a generator called "CodeBlocks", so you should start cmake like this:
   cmake "-GCodeBlocks - Unix Makefiles" <other options> $srcdir;
3. If you already have a CMake build tree, you can add a new generator (or any other options) by using the undocumented -H and -B options:
   cmake "-GCodeBlocks - Unix Makefiles" -H$srcdir -B$builddir;
4. Once I did that, I could use Qt Creator's very useful "find definition" F2 shortcut to navigate the code. It came in very handy as well when I was debugging D-Bus last week. And note that D-Bus uses an automake/autoconf-based buildsystem which is not supported yet;
5. The CMake support in Qt Creator lets you choose which targets to build and to debug. The list was impressive when I loaded kdebase;
6. Debugging Plasma inside Qt Creator is possible;
7. However, debugging my problem in Qt Creator was extremely slow. Apparently having 120+ stack frames slows things down considerably (but I hear it's being worked on already);
8. Turns out that the 120+ stack frames should have hinted me to the problem in Plasma (having three nested paint events was the clue);
9. If you're step-by-step debugging Plasma, the clock doesn't get updated,

On that last thing, here's how I found out: I was debugging Plasma while in a phone conference, and every time I looked at my clock, I wondered, "Time is going slow today, it's still 14:25. This phone conference seems like it's never going to end". I really should have clued in by the third time...

The remaining things I would like to see fixed (they're by now only annoyances):

• The NVidia binary Open GL libraries are compiled without -fPIC. This means every single process that links to libGL.so on Linux automatically uses 10 MB of non-shared memory, at load time, and there's nothing we can do about it. This affects every user of the binary drivers, regardless of desktop.
• My keyboard has a few extra keys labelled 1 to 5 that xev recognises, but I can't get them to work as application switchers with KWin. I've heard that this is related to a Qt issue (have you ever tried to set a shortcut and the KDE dialog tells you "the key you pressed is not supported by Qt"?), but I have yet to see some confirmation on the issue. If you know this to be a bug, please report it.

And, oh, it's now way over a month since my last blog when I said the snow was melting away... we're now in April and the snow is not completely gone yet.