Blog

I built a recent kernel with tickless idle enabled because the laptop fan had begun running while the machine did apparently nothing. I expected the new kernel to become silent by virtue of one configuration option. It did not. The fan is apparently not impressed by release notes.

My naive test was to leave a terminal open, wait a minute, and compare the battery estimate. That number wandered by nearly an hour between readings. I then watched processor usage, which stayed close to zero while the fan continued. Neither test told me what was waking the processor.

The periodic timer tick normally interrupts each processor at a fixed frequency so the kernel can account for time and perform scheduling work. During idle periods, those interrupts wake an otherwise sleeping processor for very little purpose. Tickless idle programs the next timer event instead, allowing a longer uninterrupted sleep. It cannot help if an application or driver requests a timer every few milliseconds.

On my machine, an application polling for status updates was doing exactly that. Closing it reduced wakeups dramatically and the fan eventually slowed. A network driver also produced regular activity when the interface was unused. Disabling the interface for a test separated that problem from the timer configuration.

Measuring several idle intervals also mattered. One short sample could be dominated by mail checking, disk flushing or my own impatient mouse movement.

There are limits to the name. Tickless does not mean the kernel never uses timer interrupts, and the current work mainly avoids ticks while a processor is idle. A busy processor still needs scheduling and accounting. Hardware timer support matters too; unreliable timers can turn a power improvement into missed timeouts or clocks that drift.

The practical lesson is that tickless operation removes one systematic source of wakeups. It does not forgive programs that poll constantly, nor drivers that chatter with hardware for entertainment. I am keeping it enabled because idle residency improved and battery measurements over several complete runs are better. But the useful debugging question is now “who wakes the processor?” rather than “is CPU usage low?” Zero percent can be composed of thousands of tiny interruptions, which is a very computer-like definition of resting.

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.

I used Dolphin for an afternoon to organise a directory full of source archives. The job required renaming files, opening terminals in several directories, comparing sizes and moving groups into subdirectories. This is exactly the sort of ordinary task that reveals more than a polished screenshot.

My naive attempt was to configure Dolphin until it behaved like my Konqueror file-management profile. I looked for the embedded terminal, detailed per-directory view controls and several service actions. Some were absent; others were simply in different places. I initially treated every missing knob as evidence that Dolphin was too simple.

Once I stopped reconstructing Konqueror, the design made more sense. The places panel, breadcrumb path and split view cover most navigation without exposing the browser machinery. The information panel is useful when it updates promptly. The interface has fewer opportunities to turn into an accidental control room, which is not entirely bad.

Remembering view settings per directory would make that restraint easier to accept for folders with genuinely different purposes.

There are real limitations, though. Keyboard focus between the location bar, places and file view is not always obvious. Preview generation can make a directory feel sluggish, and cancelling it does not seem immediate. A failed file operation gave me less detail than I wanted. Split view is promising, but it needs unmistakable indication of which side will receive the next action. Guessing wrong while moving files is a fine way to learn new vocabulary.

The mechanism behind some differences is that Dolphin is deliberately a file manager, while Konqueror is a host for many components. That narrower job permits a cleaner interface, but it also means a feature does not appear merely because some embeddable part already exists elsewhere in KDE.

I will keep Konqueror for browsing and complicated remote work for now. Dolphin is already pleasant for local files, provided previews are used selectively and I do not demand every historical option on day one. Simplicity is valuable when it removes decisions, not when it removes information needed to recover from a mistake. Dolphin is near that balance, but it has not found it everywhere yet.

I wanted to draw a simple network diagram: a few hundred boxes, some labels, and lines joining them. My old version used a custom widget with a large paintEvent(). It worked until I added selection, dragging and zooming. Then every mouse press became a small geometry examination, and every repaint redrew the universe.

Qt 4.2 already had Graphics View, but I postponed learning it because the three principal classes sounded like bureaucracy. This week I finally moved the diagram to QGraphicsScene, QGraphicsView and a handful of QGraphicsItem subclasses. Naturally, my first implementation reproduced most of the mistakes from the custom widget, only with newer nouns.

I created every item at viewport coordinates and moved them whenever the scroll bars changed. That made scrolling jitter, selection rectangles miss their targets, and zooming move the diagram away from the mouse. I then tried compensating with more coordinate conversions. By noon I had code converting a point from the view to the scene, back to the view, and possibly into a neighbouring dimension.

The useful idea is that the scene owns a stable logical coordinate system. Items live in scene coordinates, while the view is merely one camera onto that scene. Scrolling and zooming alter the camera transform; they should not rearrange the objects. Mouse positions arriving at the viewport can be mapped into the scene once, at the boundary, and item-local coordinates can be left to the item.

After removing my scroll-bar corrections, panning became smooth. Scaling the view around an anchor also stopped corrupting the stored positions. More importantly, a second view could display the same scene at a different zoom without duplicating the graph. That one experiment explained the separation better than the class names did.

Painting required another correction. My naive item painted outside its boundingRect() to make room for a shadow. Sometimes the shadow remained on screen after the item moved, producing a trail that looked like a very cheap supernatural effect. The scene uses the bounding rectangle to decide what may need repainting and which items intersect an area. If the paint escapes that promise, the scene has no reason to clean it up.

I expanded the rectangle to include the pen and shadow, then supplied a tighter shape() for hit testing. Those two concepts need not be identical. The bounding rectangle should be cheap and conservative; the shape can describe the clickable outline more accurately. With that split, selecting a line no longer required clicking somewhere in its enormous rectangular aura.

Performance was my next concern. I assumed one item per node, label and connector would necessarily be slower than one giant paint function. At first it was, because each node recomputed text dimensions and connector paths during every paint. Caching those values when the data changed made a larger difference than reducing the item count. The view can already avoid painting items outside the exposed region, something my giant widget did not do intelligently.

There are still choices rather than magic switches. Device-coordinate caching helps items that do not change but are viewed repeatedly; it is less attractive for items constantly transformed. Indexing the scene accelerates lookup in a mostly stable diagram, but updating an index while thousands of objects move can cost more than a simple scan. The correct setting depends on whether the scene behaves like a map or like a box of agitated insects.

The new event handling is also cleaner. Instead of asking every object whether a mouse point belongs to it, I let the scene deliver events to the topmost suitable item. Movable and selectable flags cover ordinary interaction. A custom item only handles a mouse event when its behavior is genuinely special. This removed an entire home-grown selection system, including one bug where hidden nodes could still be dragged.

Qt 4.3 adds useful refinements, but the important lesson is already present: Graphics View is not a faster canvas. It is a retained scene with explicit geometry, coordinate mapping, event delivery and multiple views. It rewards honest descriptions of where an item is and what it paints. Lie about either and it retaliates with artifacts that appear random but are, annoyingly, deserved.

My practical conclusion is to use a plain custom widget for drawings that are truly one object and have simple interaction. Once the drawing contains independent things that move, select, overlap or need more than one view, Graphics View earns its three-class introduction. Start in scene coordinates, keep bounding rectangles accurate, cache computations rather than blindly caching pixels, and let the framework perform the hit testing. It is less code, but only after deleting the code written to defeat it.

I tried the latest Oxygen icons today and immediately decided the whole desktop looked better. Then I used it for an hour and discovered that “looks better” and “is easier to read” are not synonyms.

My first attempt was to set every available Oxygen component at once: icons, window decoration, widget style and colours. The result was certainly consistent. It was also difficult to distinguish a few small toolbar actions, especially disabled ones. At 16 pixels, subtle gradients become subtle grey soup.

The mechanism is mundane. An icon theme must communicate shape at several fixed sizes, not merely survive being scaled down from a handsome drawing. The new SVG source helps artists produce multiple sizes and keeps larger icons crisp, but it does not remove the need for deliberate small variants. A tiny icon has almost no room for texture, perspective or philosophical nuance.

I switched the toolbar to larger icons and kept text beside the less obvious actions. That made Dolphin and the configuration tools much easier to scan. I also stopped blaming Oxygen for missing actions and unfinished panels. Artwork can make incomplete software pleasant to inspect, but it cannot implement a file operation through sheer shininess.

Oxygen already gives KDE 4 a strong identity, and I prefer its restrained colours to the louder themes I usually replace after five minutes. Still, visual consistency is only useful when the symbols remain distinct. My practical conclusion: judge icons at the size actually used, not in the preview window. The preview window is where all icons go to lie about their career prospects.