* 2.3.2009
53cm, 3620g

If you want to help translating GIMP to your language, please get in contact with the GNOME translation team for your language and offer your help. Please do not send me or other GIMP developers translations. As we most probably don’t speak your language, we can’t judge the quality of the translations. It’s the job of your translation team to do this. So if you want to contribute, please join your team.

Ubuntu Hardy doesn’t have the latest WebKit release packaged. So I have backported the packages from Intrepid. Use at will, but don’t blame me if it doesn’t work. It works fine for me.

My main grief with this is that I implemented the download of the help index using GIO. From a programming point of view this works nicely for local and online help. And in fact it does work nicely on a system that has the HTTP backend installed. But I only just realized that there is very little chance to get this to work on the Windows platform. It appears that only local file I/O is implemented for Win32. That renders GIO/GVFS pretty much useless for a cross-platform application like GIMP. Is there any hope that this could work in time for the 2.6 release? Or do I really have to go through the hassle of adding extra code for Win32, probably using libcurl?

Since this problem is unlikely ever to be fixed in GTK+, we had to find a solution in the GIMP Print plug-in. The solution is to behave like other applications and to offer this functionality in a dedicated menu item labelled “Page Setup”. This is handled in bug #513291.

Working on this bug gave the opportunity to improve some other aspects of the Print plug-in. It now uses less memory, the preview has become faster and provides better feedback when you adjust the image on the page. Without the button, the dialog also looks less cluttered:

The tile pyramid consists of a series of scaled down copies of the image. On level 0, we have the original projection created by combining all layers. Level 1 is a quarter of the original size, level 2 a quarter of the size of level 1 and so forth. So when the projection changes, in order to recompute one pixel on the upper level, four pixels from the pyramid level below are averaged. To do this correctly, the pixels have to be weighted by their alpha values. And this is where a lot of CPU cycles are burnt.

I have committed some changes to trunk last night that make the tile pyramid store the pixels in the upper levels with pre-multiplied alpha. Now averaging four pixels is as simple as adding their values and shifting the result two bits to the right (thus effectively dividing by four). Of course this means that the display rendering code had to be changed as well. But it turned out that this code also benefits from pre-multiplied alpha. It became simpler and we don’t any longer need the huge lookup tables that we used to use to blend the image pixels over the checkerboard pattern.

The graphics shows the time GIMP needs to recompute the image projection and to render it to the screen. I’ve measured this for a rather large image (10800 x 4856 pixels) and the time went down from 1.83 seconds to 1.45 seconds. This is an improvement that you actually notice as a user.

Two weeks ago I have been interviewed by Tim about GIMP. We talked for two hours, about the 2.4 release, history of GIMP, current development and our plans for the future. If you understand German and have enough time to waste to listen to a two hour podcast on GIMP, you may want to follow this link.

There is a lot more to do here. As a next step I plan to introduce buffers and tile-managers with pre-multiplied alpha in GIMP. This will speed up rendering of the previews and the image display and it will help with the transition to GEGL.

Over the next week we will try to come up with a list of tasks that we want to commit ourselves to, for GIMP 2.6 and beyond. When we can achieve that, I expect development towards GIMP 2.6 to gain a lot of momentum.

The Screenshot plug-in can now capture an image of the mouse pointer and it will put it on an extra layer so that you can easily adjust it later. This makes use of the X Fixes extension.

Now we are going to celebrate the release. And when things have settled a bit, we will discuss the roadmap for 2.6. All I can tell so far is that GIMP 2.6 is going to rock. And that it will definitely not take as long as it took to finish 2.4.