For the love of eye-candy

Compiz-fusion is lovely, it really is... spinny cube, sproingy windows, neat effects - and even some stuff that's genuinely useful when it comes to organising today's clutter of windows. In short, I like it and find it just useful enough that I'd really hate to have to do without it.

Of course, since this is a Really Cool Thing that I really like, there are some problems. And, of course, these are problems that nobody else in the whole wide world seems to have suffered from, at least as far as google can see (and I've searched and searched and searched...).

I'm actually fairly used to not finding stuff with google - generally when I have a funky problem all I can find is forum posts by other people with the same problem, and maybe something in a language I don't understand that looks like it might be relevant, but isn't.

What makes my compiz woes so much more interesting is that for once I can't even find other people with the same problems. Sure, I can find a few people with problems that look a bit similar at first glance but turn out to be quite different, and I've read plenty of those pages just in case their problems actually turned out not to be that different after all. No joy.

It's not even one thing, either. There are three major problems I had with compiz, of which one is solved, one is mostly worked around, and one continues to baffle and frustrate me. Since I had such a bad time of searching for help on these problems, I figured it was probably worth writing them up a bit. Maybe I'm not so alone after all and somebody will descend from heaven to tell me how to fix them properly. Or maybe what I've discovered will help somebody else in the same position that I was.

Just to add to the fun, I'm unable to reproduce these problems on other boxen locally, even with cloned configuration. And, speaking of configuration, the problems exist for a completely 'clean' user also, so it's not some hairy old piece of config lying around in my setup. But, of course, only on my box.

Anyway... First of all, some background info: I'm using x86 Fedora 8, which has compiz-fusion 0.6. My boxen are all AMD/Nvidia based. The specific box that has the trouble is an Athlon64 X2 5200 with 2GB of RAM and an 8600GTS card (I'm using the x86 architecture to keep things homogeneous here). My desktop environment of choice is KDE (3.5.8), but again that seems to be irrelevant - the 'clean' user has the Fedora default of GNOME.

"Problem 1, if you were an ice-cream, what flavour would you be?"
"Choc-chip, so I could get smeared all over you and leave big splotchy marks."

Problem number 1 is the solved one - a simple change to my xorg.conf file sorted this one out, but I'm getting ahead of myself.

Shortly before I started using compiz in earnest, I discovered VirtualBox and was happily using it to host various OSes for testing/compatibility/whatever. With compiz on the scene, it all started going a bit wrong... whenever the VB window resized there was heavy screen corruption around it. Occasionally the whole X server would crash. Not good, in other words. Smacks of driver/X bug, or similar. It's also worth noting that this problem isn't actually a compiz problem - the exact same thing happens with KDE's compositing manager - it's just that compiz is probably the most common compositing manager out there, and the one I had the problem with.

As it happens, as part of troubleshooting problem 2, I'd made some changes to my xorg.conf file as recommended in one of those 'not quite the same problem' forum topics. The specific change that lead to the problem seems to have been enabling backing store, thus:

Option "BackingStore" "True"

(Incidentally, that didn't make any difference to the problem). Removing that line from the xorg.conf file sorted out the corruption, and now VirtualBox is running just fine again. Yay.

"Problem 2, what would you be doing while you waited for me to get ready to go out?"
"I'd be looking at pictures of old flames."

Problem 2 is my "mostly worked around" one, for those keeping score at home.

I use the 'Animations' plugin in order to have the beam effect for minimised/restored windows, and the burn effect for closed ones. Oh, and some zooming for newly opened windows. All in all, it makes for a visually cool desktop that somehow feels a little more 'tactile' than one where windows just appear/disappear 'whole'. It gives the windows some sort of 'life', elevating them above being mere rectangular regions of a rectangular screen. And, naturally, I'm not willing to do without it. If my windows don't burn when I close them, they might as well not do anything.

So, what's the problem? Well, if I leave my box idle for any significant length of time, for instance overnight (or overday, I suppose - I tend to being nocturnal) then the next animation to be displayed gets jammed for several seconds. The length of the 'jam' seems to be proportional to the period of inactivity, and until it sorts itself out the entire X session is wedged. The effect is noticeable after even an hour or two of inactivity, but really comes into its own after a night/day or so.

What happens is that the effect begins to play, then freezes. So, if I close a window then the fire effect will render its first frame and then everything comes to a complete standstill. The same happens with the other effects provided by the Animations plugin, but not for ones provided by other plugins. My wobby windows are fine, my cube rotates, etc., etc. But that first 'animation' effect gets stuck, with 100% CPU load.

The box is still running fine while this is happening - I can ssh in to it just fine, for instance. I can't switch to a VC though - X handles that, and X is frozen until the effect finally deigns to finish playing several seconds later.

So, what's my workaround? Well, since the Animations plugin is the only one affected, and since I'm hardly likely to miss it when the machine is sitting there with the monitor off, I knocked up a little script that watches for the monitor being turned off by DPMS and disables the Animations plugin. When the monitor is turned back on, the script (re-)enables the plugin. Overall effect: problem solved as long as DPMS corresponds to idle time, which it pretty much does.

The script (and a little more info) can be found here.

"Problem 3, sometimes I feel like my clique is out of control. What alternative could you provide?"
"None. And I'd be sure to get you out of those shift dresses, too."

Ah yes, problem 3. My current Nemesis. The Unsolved One. The great Dunno. Etc.

I make heavy use of VNC: my 'media player' box runs Amarok in a VNC session, my IRC client is also running on that box and accessed via VNC. VNC is great - it's screen for X servers, and what's not awesome about that? Nothing, that's what. Sadly, VNC becomes a good deal less useful if you can't actually use it properly, say if certain mouse-clicks or key presses didn't work. And that's what's happening to me.

Specifically, I can't use the Control, Shift or Alt keys in combination with the mouse buttons. They just get ignored completely and the click happens as though I wasn't pressing any keys at all. Naturally, this makes it rather hard to do various things that require shift/ctrl/alt-clicking/dragging something - and there's actually quite a lot of things like that, as becomes abundantly clear when your ability to do them goes away.

My VNC client of choice is the standard RealVNC vncviewer as installed from the Fedora repos. Before compiz all was well, but now no modifiers. Naturally, I've tried some other VNC clients with mixed results. TightVNC has the same problem, but a really old tightVNC client I have lying around for some reason doesn't. Vinagre doesn't have the problem, either, but it's not really useful for how I use VNC.

So currently I'm stuck using an old tightVNC whenever I think I'm going to want to shift/ctrl/alt-click /drag anything, which sucks.

Try as I might, I can't get the other F8 box here to behave like this - it just works there.

Gah.