<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>X11 on Roberto Selbach</title><link>https://rselbach.com/tags/x11/</link><description>Recent content in X11 on Roberto Selbach</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Thu, 18 Sep 2008 19:05:00 +0000</lastBuildDate><atom:link href="https://rselbach.com/tags/x11/index.xml" rel="self" type="application/rss+xml"/><item><title>KWin Compositing Without the Circus</title><link>https://rselbach.com/kwin-compositing-without-the-circus/</link><pubDate>Thu, 18 Sep 2008 19:05:00 +0000</pubDate><guid>https://rselbach.com/kwin-compositing-without-the-circus/</guid><description>&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;This week I used a repeatable little test instead. I dragged the same terminal across the same busy screen for thirty seconds, watched KWin&amp;rsquo;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;So compositing stays on, blur stays off, and I have notes I can repeat after the next driver update. &amp;ldquo;Feels slow&amp;rdquo; gave me one giant switch. A crude measurement found the smaller one.&lt;/p&gt;</description></item><item><title>Two Roads to Composited Windows</title><link>https://rselbach.com/two-roads-to-composited-windows/</link><pubDate>Wed, 02 Aug 2006 21:03:00 +0000</pubDate><guid>https://rselbach.com/two-roads-to-composited-windows/</guid><description>&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-sh" data-lang="sh"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;glxinfo | grep direct
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;xdpyinfo | grep -i composite
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;compiz --replace gconf decoration move resize
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;I prefer AIGLX&amp;rsquo;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description></item></channel></rss>