X11

I used to respond to a sluggish desktop by disabling compositing. That made the lag disappear, but also threw away the only useful fact: something in the composed path was expensive. It did not say whether the problem was KWin, one effect, the backend, or the driver.

This week I used a repeatable little test instead. I dragged the same terminal across the same busy screen for thirty seconds, watched KWin’s Show FPS display for missed frames, and recorded KWin and X CPU use. It is not a laboratory benchmark, but it is consistent enough to compare one setting at a time.

With all effects enabled, resizing caused regular stalls. Suspending compositing was the baseline, not the fix. I turned composition back on and disabled effects one by one. Blur was the expensive one on this hardware; the compositor with shadows and ordinary transitions stayed smooth. Disabling everything had hidden that distinction.

The FPS overlay needs some skepticism. A high frame count does not prove input feels responsive, and displaying the counter adds work of its own. I care more about visible pauses during the same action and whether CPU time changes in the same direction. Numbers are useful here as comparisons, not medals.

I repeated the run with OpenGL and XRender. XRender used a little more CPU but had steadier frame delivery with this driver. That is a local result, not a declaration that one backend is universally faster. Different cards and drivers can reverse it.

So compositing stays on, blur stays off, and I have notes I can repeat after the next driver update. “Feels slow” gave me one giant switch. A crude measurement found the smaller one.

I enabled Compiz on a test machine today and immediately lost window borders. The cube worked, naturally. A desktop may be unusable, but at least it can be unusable on six rotating faces.

The experiment clarified three pieces that are often bundled together in conversation. Compiz is the compositing window manager. It asks the X server for redirected window contents, combines those textures, and draws the resulting scene. Xgl is an X server built on top of OpenGL. AIGLX takes a different route by adding accelerated indirect GL rendering to the conventional X server and driver path.

That difference affects setup and failure modes. With Xgl I start a separate server and run the session inside it. With AIGLX I keep the normal server architecture but depend on suitable server and driver support. Neither route makes every driver correct by declaration.

For diagnosis I first remove decoration and plugins from the mystery. I run a plain window manager, confirm direct rendering information, then add composition. Useful checks include:

glxinfo | grep direct
xdpyinfo | grep -i composite
compiz --replace gconf decoration move resize

The exact plugin names and options are changing, so this is a notebook entry rather than scripture. The important mechanism is staged testing: server extension, GL path, window manager, then decorator.

My missing borders came from the decorator not running, not from texture rendering. Starting it restored frames, though resizing still exposed corruption with this driver.

I prefer AIGLX’s direction because it preserves more of the existing X server arrangement and avoids nesting a whole desktop on another server. The caveat is substantial: today Xgl may work better on a particular proprietary driver, while AIGLX support and performance vary. Architecture preferences do not repair hardware support.

Before comparing speed, I also verify that both tests use the same resolution, colour depth, effects, and driver. Otherwise the benchmark measures configuration drift with impressive precision.

These experiments are useful for KDE 4 because they reveal what a composited desktop might rely on, not because spinning windows constitute a completed desktop design. Effects must degrade gracefully, input must remain correct, and ordinary two-dimensional work must not become collateral damage. I have disabled the cube for now. It was beginning to look smug.