When dealing with images, the situation becomes especially worse considering the fact that photo resolutions are ever increasing. Image sizes of 4500×3000 pixels (or more) are not uncommon. Uncompressed, this amounts to 40 megabytes for 24 bits/pixel, and having to wait several seconds for the image to load or save is annoying.

London Bridge (Tower Bridge) : Reflection on the River Thames
Photo byAnirudh Koul at Flickr

JPEG, the de-facto standard for image compression, while still one of the fastest methods available, has one major drawback: it compresses lossy, in other words, whenever the image is saved, some fidelity is lost. For situations where multiple load/save cycles are to be expected, for example in photo manipulation applications, this is inacceptable.

In the recent months, I have been evaluating available lossless image compression algorithms to select one that is fast, but also good in compression efficiency.

Looking at the Lossless Photo Compression Benchmark I was a bit disappointed to find out that PNG, while quite fast in decompression and offering moderate compression rates, is very slow when compressing images.

The JPEG-LS format, being significantly faster at compression compared to PNG, and even offering improved compression rates of about 15%, seemed a good choice at first. It has, however, several drawbacks: Not only is it slower than PNG in decompression, but HP also has a patent on the used context modeling. No-Go.

What does a programmer do, when he is not satisfied with what is available? Right, he re-invents the world, only to make it better: Last week, I released the initial version of ImageZero (iz, pronounced “easy”), a high-performance lossless RGB photo codec.

Being twice as fast as PNG when decompressing (and more than 20 times faster when compressing) it achieves compression ratios that are near or better than PNG for natural photos, sometimes even better than JPEG-LS for very high quality photos. ImageZero is not intended for grayscale or artificial images, but I may improve the algorithms for those image types.

Method	File Size	Compression	Decompression
uncompressed	46380 KB	-	-
JLS	14984 KB	6.6 s	7.3 s
PNG	16256 KB	42.4 s	2.4 s
IZ	15496 KB	1.2 s	1.3 s

The used algorithm is really easy: the per-pixel compression and decompression is done without any branches (except for a single branch in the bit coder), so that on today’s super scalar CPUs it can be executed very fast.

Possible uses include:
- image/thumbnail databases
- backing store for image processing apps
- future icon format

If you are interested, please help shaping the library API and file format for .iz files. We can use the kde-imaging mailing list for discussion.

• kded4 crashes
• kded4 leaks memory
• kded4 eats 100% CPU
• kded4 <defunct> process

Before I dive into troubleshooting those problems, let me explain what kded4 does and how it works.

Little Demons Everywhere

In the Plasma Workspace there is a widget to show notifications when the battery goes low. But how does the widget know when this happens? It could just check the battery level every couple of seconds, but this would waste CPU cycles. Instead, many ACPI BIOS implementations can trigger hardware interrupts to notify the operating system about the battery state.

Now Plasma could connect to the OS directly, but this would mean it will not run on other operating systems. The solution is a daemon which has OS specific backends. They watch those OS signals and Plasma can connect to the daemon’s interface (usually via D-Bus) to learn about the battery’s health.

Thus a daemon is small process that often just sits there and waits for OS events and triggers simple actions. KDE needs daemons to watch the network, the printer ports, the screen brightness hotkeys, the mounted disks, etc.

With the numbers of daemons we need, but with the very little work they do, it makes sense to use a single process for all of them. The key advantage is less memory usage, and this is exactly what kded4, the KDE daemon process, exploits: To enable the various daemon functionalities, it loads specialized kded modules instead of needing a separate process for each of them.

The Crux of kded4 Bugs

The downside of this approach is that bugs in any of those modules can be fatal for the complete process; in other words, every module must function correctly for kded4 to operate successfully. Which brings us back to the bugs: Some modules still have issues.

Lets say someone reports a problem about growing kded4 memory usage. With the above description in mind, it is easy to understand that – without further analysis – the bug could be in any module, or even in multiple of them. Since the set of modules that developers use might be different than what the reporter used, and the daemons often only handle very seldom actions, many issues cannot be reproduced easily, and without some help from the bug reporter, those problems often cannot be fixed.

The following checklist should guide you through the steps required to troubleshoot kded4 bugs and help collecting information needed to fix them.

Make Sure the Bug is Reproducible

Some bugs only show once. You installed an update, and on next reboot, kded4 crashes, maybe because some configuration files were not correctly updated yet. On subsequent reboots, it works fine without a crash. What to do? Most people do not save previous configuration files, so even when going back to the old version before the update, the crash might never happen again.

You plugged in a headset, and kded4 starts consuming 100% CPU cycles, maybe because a new device triggers a bug in underlying Phonon modules. If you restart, this bug never happens again, because Phonon might “remember” the headset, and not trigger the bug on this code path. Worth a report?

You log out of KDE, noticing you have hundreds of hanging (defunct) kded4 processes lying around. After killing them all and logging in again, there is only a single kded4 process, and that correctly terminates on logout, so you might think the problem was only temporary. The reason is that the process might only hang when a module performs a certain action; it is never the logout per se that makes kded4 hang.

Related are problems that show when kded4 hangs or does not run at all. The symptoms are often completely unrelated. For example, people notice cookies in Konqueror not working, and the usual cause is kded4 not running. Some module might prevent it from starting, or cause it to hang, e.g. waiting for an event that never happens. Of course, these issues should also be fixed.

If you want to report such a bug, make sure you can reproduce it. Try finding old configuration files, try reverting to previous versions, try to find out what steps or actions are required to trigger it. Use the top console command to verify if kde4 really consumes CPU cycles or eats memory. If you cannot reproduce, there is little chance we can. Bugs that never go away are easier, but that does not imply we can see them, too.

Isolate the Offender

The next step is to find out which module is responsible. Without this information, there is often little we can do.

Disable kded4 modules in System Settings > Startup and Shutdown > Service Manager. Some modules cannot be disabled there or automatically start even if you disabled them. To disable such a module, remove its .desktop file from /usr/share/kde4/services/kded/, run kbuildsycoca4, and restart kded4. (Move them to a place where you can easily restore them. This requires root privileges.)

Regularily retrying to reproduce the bug with some modules disabled should eventually lead to the offender. Of course you should start with the “obvious” candidates. For example, if a problem shows when plugging an audio device, the fault is very likely in the phononserver module. For crashes, the offending module can often be found in the complete backtrace.

But sometimes the bug is only triggered by specific combinations of modules, so some patience trying to find them certainly helps. If the problem is reproducible regardless of modules, the bug might really be in kded4 itself, but this is very unlikely from looking at last years bug reports.

Check Existing Bugs

Before filing a new bug report, you should check existing reports for similar or identical problems. If you add a comment with your findings it may be the determining factor for fixing the bug. If you found no similar report, add a new one. Ideally you report it against the module which is responsible.

Note that some distributions might add additional distribution specific modules, in particular to check repositories for software updates. Bugs for those modules should be reported to the bug tracker of your distribution.

In any case, if you are not sure about any of above steps, you might contact KDE forums to ask for help. Even if you cannot provide all required information, it is better to write a report for a new bug, instead of hoping someone else does. Only if you want to see it fixed, of course.

In the latest 0.0.7 version, support for shadows, animations, and button glow has been added. Additionally, many bugs have been fixed, and it should now support all Emerald themes, including those that do not provide its own button pixmaps.

If you want to test Smaragd, make sure you first try without custom button positions enabled in System Settings. Smaragd is then able to use the button positions from the theme and this guarantees best results. If you later would like to swap some buttons, or remove some, then you can enable custom button positions.

To manage your downloaded themes, you can use the following command (if you did not install KDE4 to /usr, then you have to adjust the path):

khotnewstuff4 /usr/share/kde4/config/smaragd.knsrc

This downloads .emerald theme files to the .kde/share/apps/smaragd/themes folder. To select a theme, extract one of those .emerald files to .emerald/theme/ and restart KWin. Make sure you delete any old theme files you had in .emerald/theme/ before you extract a new .emerald file.

Please report bugs or suggestions to http://kde-look.org/content/show.php/Smaragd+(Emerald+for+KDE)?content=125162 or add a comment here.

Sounds used to be enabled since ever, but a little bug prevented the messages from triggering any notifications.

If you like the old behavior, disable the sounds using “kcmshell4 notify”, component is “KDE Workspace”, and the actions are all called “Messages”.

The fix is not in KDE 4.5 RC1, but will appear in the second release candidate.

This version is not yet ready for production use (there are no shadows and theme installation has to be done manually), but you can already start choosing your favorite theme out of over 1500 available Emerald themes.

For details, see http://kde-look.org/content/show.php/?content=125162

The goal is to render a two-dimensional gradient as depicted below. The current implementation allocates a properly sized QImage, and computes the RGB color values for each individual pixel.

Hue/saturation two-dimensional gradient

This requires, however, nearly hundred thousand conversions from HSV to RGB color values, and is the primary cause for the slowness of the dialog.

When looking at the resulting RGB values, you will notice that each row (“scanline”) is actually a one-dimensional linear gradient, so it could be rendered using QLinearGradient.

Looking further, you will also see that there is a linear gradient in each column. Such a gradient is called “bilinear”, but Qt does not offer a two-dimensional QGradient class.

The trick is to create this bilinear gradient by scaling up a very small QImage. The image you see above is actually only 7×2 pixels large. The image is then rendered to a larger QPixmap with scaling applied, so that possible hardware scaling can be used.

A requirement is that pixmap scaling supports bilinear interpolation. This mode, however, is even available with the software scaling algorithms built into Qt.

When I ported it to KDE 4, I did not try to improve it in any way; my first goal was to have it available at all. The only new feature in deKorator 0.4 was support for transparent themes to make use of the ARGB ability of KWin 4.3.

Today, deKorator version 0.5.1 has been released, and it comes packed with a whole lot of new features and bug fixes. I was too lazy to update the ChangeLog file (you can get the svn log from playground/artwork/dekorator, though), but since the changes need to be documented somewhere for theme writers, I decided to write a small “changeblog”.

Improved theme installation and selection

The most often reported bug required a rewrite of the theme selection dialog.

When you installed a theme and clicked on it in the list, it was not selected as the current theme, but you had to “apply paths” first. The feature to set individual paths has been removed from the dialog; simply clicking on a theme selects the paths automatically (you can still set them in the config file manually).

Improved detection of theme files

Another problem was that installation of themes often failed because of the strict naming requirements. Now the detection is much better, it even detects old deKorator 0.1 themes, and tries to find decoration archives inside the installed archive. Some themes still do not install correctly because of wired bugs in the theme files. For example, there are themes that have the “deco” and “buttons” directories directly in the root of the archive, without any directory for the theme name …

GetHotNewStuff support

For many themes, installation can now be done directly from the KNewStuff interface to the openDesktop.org site “kde-look.org”, where over 150 deKorator themes can be downloaded.

Thanks to improvements in the coming KDE SC 4.5 release, you will even be able to rate themes or upload your own themes. With that, we come to a feature that will be appreciated by theme creators.

Separate images for inactive windows

User “Shirakawasuna” requested a set of different images for buttons on inactive windows, and later suggested to use Emerald compatible button files. This has now be implemented in deKorator 0.5.1.

Inside the “buttons” directory, there are usually the directories “normal”, “hover”, and “press”, but you can now also place a single file for each button type directly inside the “buttons” directory. The file has to be named “buttons<Type>.png”, where <Type> is “Close”, “Max”, “Min”, “Restore”, etc. as before.

This file must have six images in a single row, all equally sized. The order is “normal”, “hover”, “press” for active windows, then “normal”, “hover”, “press” for inactive windows. For compatibility, you should keep the old individual button files until the new version has been adopted by users.

Note: When porting Emerald themes, you have to rename the files, e.g. from “buttons.max.png” to “buttonsMax.png”. You might also need to add some transparent padding to get them aligned correctly within the frame, as deKorator always centers images that are smaller than the frame.

Additionally, you can now also supply separate images for the frame of inactive windows.

Inside the “deco” directory, you can place a directory named “inactive” with the same file layout. You do not need to add all images; those that are not provided are used from the “deco” directory.

I hope that these improvements give theme writers more freedom in their design or porting efforts; I am looking forward to new themes, maybe even some with real alpha transparency.

Bug fixes in deKorator 0.5.1

• Fix borders on maximized windows (requested by user “Shirakawasuna”)
• Fix resize region with small borders (thanks to “Shirakawasuna” for reporting the issue, clearly seen on his “Dots” theme)
• Fix “hand” cursor over buttons (requested by “Shirakawasuna”)
• Fix possible crash with NoBorder option (reported by “Ace2016″, thanks!)
• Fix large images being cropped instead of scaled (reported/requested by “Shirakawasuna”, clearly seen on his Reluna-Bluetiful port)
• Fix stuck windows when shading windows with masks (this was first reported by “Thailandian”, and later “greggel” found out how to trigger it. Thanks to both!)
• Fix spelling mistake for masks (found by “Shirakawasuna”)
• Fix wrong button image “StickyDownPress” used instead of “StickyPress” (thanks to user “greggel” for reporting)
• Fix partial transparency on button backgrounds (that bug was unnoticed, because there are no partially transparent themes yet)

If you find anything else that needs to be improved, please use the bugs.kde.org bugtracker.

Source code and packages for all major distributions are available for download from the kde-look.org site. Note that these packages are not official; you should switch to distribution packages once they are available.

Being a math teacher is not easy; your students hate you for that fact alone. And I have a habit that makes them hate me even more: When there is something wrong with their math, I usually do not help immediately. Instead, I keep saying “look at it again!”, not even telling them where their mistake is. Only eventually they give up, and I need to guide them to the correct solution.

Okay, to tell the truth, they fully support my “bad habit”, because they learn a lot this way. A good mixture of reasoning, patience, and pedantism cannot be bad.

Now, why am I telling you all this?

Today, I closed three bug reports about crashes inside KDirWatch, all duplicates of the well known inotify crash bug that is happening since 4.0. The backtraces were, however, a bit different, and so I asked David Faure (our KIO maintainer) what could be the reason for this.

The whole inotify handling in kdelibs is really low level, nothing a casual C++ programmer wants to look at. I did, however, look at the code some months ago, when I had the (self-imposed) mission to resolve all kdelibs crashers (I miserably failed at that, though). There was nothing wrong with the code. I swear, nothing.

Said bug often happens with updates from package managers. I was thinking about some updated libraries having a different binary layout and with all the latest fuzz about inotify bugs in Linux kernel 2.6.31, which could cause folder views to not refresh on changes, I even feared some incompatibility.

So I “looked at it again”. And guess what? The reason for the crash was obvious, David immediately saw another related bug, and we were able to create a patch in just about two hours. After committing that, I looked at the patch, and found a bug that I introduced. Fixed that, committed that. Guess what? I “looked at it again”, and saw my (hopefully) last mistake.

There is one big difference between us KDE developers and my students. We cannot give up and hope someone guides us to our mistakes. We have to “look at it again” (and again).

PS: The fix is probably too late for the 4.4 beta1 release, but let’s hope the bug is gone for good with the beta2 release.

Step 1: Make sure the application uses “appnameui.rc”

Usually if an application allows editing the toolbars, it saves its custom configuration to a file ending in “ui.rc” in the .kde/share/apps/appname/ directory. To find out if an application really uses this file, simply change the toolbar of that application using the “Configure Toolbars …” dialog, and check if said file exists. For Dolphin, the file is .kde/share/apps/dolphin/dolphinui.rc

Note: This step might crash with some applications (bug reports are already filed). The configuration file is usually still saved correctly.

Step 2: Select the action that you want to edit

Change the icon of the toolbar action that you would like to change the text on. This is only required to get the proper “Action” entry generated in the ui.rc file. There is a “Change Icon …” button in the toolbar dialog that opens the icon selector. For this example, I changed the icon for the “Compare Files” action to the “edit-copy” icon.

Step 3: Change the ui.rc file using a text editor

Load the ui.rc file in a text editor. It is an XML file. Near the end of the file there is an <ActionProperties> tag. Inside this tag all modified actions appear:

 <ActionProperties scheme="Default">
  <Action icon="edit-copy" name="compare_files"/>
 </ActionProperties>

Now delete the “icon” property and replace it with the “iconText” property:

 <ActionProperties scheme="Default">
  <Action iconText="Diff" name="compare_files"/>
 </ActionProperties>

Save the file. This will do two things if you restart Dolphin: you get the original icon back, and the icon text is changed from “Compare File” to “Diff”.

Of course a real improvement would be if translators could simply provide two translations for the action texts, but KDE cannot handle it right now without the developer providing two translatable strings in the first place. I am currently investigating a solution for KDE 4.4, that does not add burden to translators or developers, and works with existing applications transparently. If I fail, I will add text customization from the toolbar edit GUI, as shown in the screen shot.