Kwin

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.

After a driver update, newly opened windows sometimes became black under KWin’s OpenGL compositor. The same windows were fine with XRender. Turning off every effect changed nothing, which at least got the animations out of the suspect list.

The useful split was the texture-from-pixmap path. Under X11 compositing, the server redirects a window into a pixmap. KWin’s OpenGL path then uses the driver’s texture-from-pixmap support to bind that pixmap as a texture for the scene. XRender composites the pixmap through a different route. Applications had painted the right pixels; the OpenGL path was failing to present them.

I could make it happen by opening two terminals, covering one, and uncovering it. Damage arrived, but the exposed window stayed black or returned in strips. Switching to the previous driver fixed that exact sequence. The newer driver also behaved if I disabled its acceleration option, slowly.

That made a much better report than “KWin draws black windows.” I included the X server, Mesa, kernel and driver versions, the OpenGL backend, hardware identifiers, and the short cover/uncover sequence. I also noted that XRender worked. That last fact tells a driver developer far more than a screenshot of a black rectangle.

Screenshots were awkward: some captured the correct window even while the display showed black. The redirected pixmap could be fine while the texture or final scanout was stale. A camera photo was ugly but honest.

I am using XRender for normal work and keeping the failing setup available for testing. Reinstalling KWin would only replace the code that asks the driver to bind the same pixmap. The break is farther down the path, and now there is a reproducible way to reach it.

I enabled KWin’s compositing effects on an older Radeon card tonight. Transparent windows appeared, shadows looked convincing, and moving a terminal promptly turned into an interpretive dance performed at twelve frames per second.

My first response was to disable individual effects at random. Wobbly windows went first, mostly because they looked guilty. Performance improved slightly but resizing still left corruption around the window border. Turning transparency off helped nothing. The decorative suspects had excellent alibis.

The real path is longer. Applications draw their windows, the X server and driver place those results in off-screen storage, and the compositor combines them into the screen image using either OpenGL or XRender. A problem in buffer handling, texture-from-pixmap support, synchronization or damage reporting can therefore resemble a slow effect even when the effect itself does almost no work.

Switching KWin from OpenGL to XRender removed the corruption but used more processor time during movement. That points at the OpenGL driver path rather than at shadows. With a newer Mesa package, OpenGL stopped leaving fragments behind, although it still paused occasionally when opening a large window. Direct rendering tests were useful only as a basic check; a spinning gear is not a compositor workload, no matter how hypnotically one watches it.

I also discovered that forcing every optional visual feature together makes diagnosis unnecessarily difficult. I returned to a plain session, enabled compositing with only shadows, then added effects one at a time. Keeping notes about the backend and driver version made the results reproducible instead of merely emotional.

Compositing is not just confectionery. Drawing the final desktop from managed window images can eliminate ugly exposure repainting and enables useful feedback such as smooth task switching. But it places a great deal of trust in graphics paths that have not received identical testing across cards.

For this machine, XRender is presently the boring and usable choice. OpenGL is the interesting test choice. KWin should detect hopeless combinations conservatively, and drivers must improve before effects can be assumed safe. My conclusion is to report corruption with the exact card, driver and backend, not “KDE is slow.” The latter may feel satisfying, but it gives a developer roughly the diagnostic value of a weather complaint.