Once upon a time, like 5 weeks ago, there used to be the longstanding plan to, at some point in the future, port GIMP to GEGL.

We have done a lot of refactoring in GIMP over the last ten years, but its innermost pixel manipulating core was still basically unchanged since GIMP 1.2 days. We didn’t bother to do anything about it, because the long term goal was to do all this stuff with GEGL, when GEGL was ready. Now GEGL has been ready for quite a while, and the GEGL porting got assigned a milestone. Was it 2.10, 3.0, 3.2, I don’t remember. We thought it would take us forever until it’s done, because nobody really had that kind of time.

About 5 weeks ago, I happened to pick up Øyvind Kolås, aka Pippin the Goatkeeper to stay at my place for about a week and do some hacking. After one day, without intending it, we started to do some small GEGL hacking in GIMP, just in order to verify an approach that seemed a good migration strategy for the future porting.

The Problem: All the GimpImage’s pixels are stored in legacy data structures called TileManagers, which are kept by high level objects called GimpDrawables. Each layer, channel, mask in GIMP is a GimpDrawable.

/* do GEGL stuff on the buffer, like running it through a graph in order to change pixels */

Just, how would we get there? Replacing the drawable’s tile manager by a buffer, breaking all of GIMP at the same time while we move on porting things to buffers instead of tile managers? No way!

The Solution: A GeglBuffer’s tiles are stored in a GeglTileBackend, and it’s possible to write tile backends for arbitrary pixel storage, so why not write a tile backend that uses a legacy GIMP TileManager as storage.

After a few hours of hacking, Pippin had the GimpTileBackendTileManager working, and I went ahead replacing some legacy code with GEGL code, using the new backend. And it simply worked!

The next important step was to make GimpDrawable keep around a GeglBuffer on top of its TileManager all the time, and to add gimp_drawable_get_buffer(). And things just kept working, and getting easier and easier the more legacy code got replaced by GEGL code, the more GeglBuffers were being passed around instead of TileManagers and PixelRegions.

What was planned as a one week visit turned into 3 weeks of GEGL porting madness. At the time this article is written, about 90% of the GIMP application’s core are ported to GEGL, and the only thing really missing are GeglOperations for all layer modes.

As a totally unexpected extra bonus, there is now even a GEGL buffer tile backend in libgimp, for plug-ins to use, so also plug-ins can simply say gimp_drawable_get_buffer(drawable_ID), and use all of GEGL to do their stuff, instead of using the legacy pixel region API that also exists on the plug-in side.

GIMP 2.10’s core will be 100% ported to GEGL, and all of the legacy pixel fiddling API for plug-ins is going to be deprecated. Once the core is completely ported, it will be a minor effort to simply “switch on” high bit depths and whatever color models we’d like to see. Oh, and already now, instead of removing indexed mode (as originally planned), we accidentally promoted indexed images to first class citizens that can be painted on, and even color corrected, just like any other image. The code doing so doesn’t even notice because GEGL and Babl transparently handle the pixel conversion magic.

The port lives in the goat-invasion branch in GIT. That branch will become master once GIMP 2.8 is relased, so the first GIMP 2.9 developer release will already contain the port in progress.

If you want to discuss GIMP and GEGL things with us face to face, join us at this year’s Libre Graphics Meeting in Vienna, in two weeks from now, a lot of GIMP people will be there; or simply check out the goat-invasion branch and see the goats yourself.

If you have some Euros to spare, consider donating them to Libre Graphics Meeting, it’s one of the few occasions for GIMP developers, and the people hacking on other projects, to meet in person; and such meetings are always a great boost for development.

During the 3 crazy weeks, quite some work time hours were spent on the port, thanks to my employer Lanedo for sponsoring this via “Labs time”.

At the GTK+ Hackfest in A Coruña I managed to get GIMP almost completely (minus one dialog and most plug-ins) running on GTK+ 3.0.

This turned out to be a great tool for finding bugs in the new GTK+. In fact, I found quite a few of them while still completing the port. Some bugs I fixed right away, others were fixed by fellow Hackfest hackers. Even while writing this post (the image was of course cropped with the ported GIMP), two more popped up and will eventually be fixed.

One of the last remaining bits of antique code in the GIMP are the parts that talk to plug-ins, namely the plug-in handling code itself, and the PDB (procedural database) which provides a way for plug-ins to call GIMP’s internal functionality and which keeps all procedures provided by plug-ins.

Everything was organized around some crufty C-structs, lived in files without proper namespace, and was basically untouched by all the refactoring that was happening during the last few years. To illustrate the evilness: the PDB did not even really know which of its procedures were dynamically allocated, and which were constant structs that are defined at compile time (not to speak of the part where perl code generated perl code that generated perl code that…). This had to stop.

All the perl-that-generates-perl stuff had to die. Every procedure definition in the PDB files (tools/pdbgen/pdb/*.pdb, they are still perl) now looks the same: Inargs, Outargs, Code.

The homemade system to specify a procedure’s arguments and return values doesn’t exist any more. Everything is based on GParamSpec now. A lot of new GIMP-specific param specs was added in app/core/gimpparamspecs.c.

The procedure’s arguments from the same prehistoric era had to go too. Procedures now take and return everything as GValue, organized as GValueArray.

Procedures are GObjects now (app/pdb/gimpprocedure.c). Their memory-management was modernized a bit (they have memory management now). Plug-In procedures are a proper GimpProcedure subclass now (app/pdb/gimppluginprocedure.c), which made lots of code much more straightforward (they were separate structs before which had a pointer to the procedure they implement).

The PDB is now an object itself (app/pdb/gimppdb.c), instead of a bunch of global variables with some API around. The PDB instance emits signals when procedures are added or removed, so the GUI can for example create menu items for new plug-in procedures. No more direct calls from the core to the GUI via the ugly GUI-vtable.

The plug-in system is a similar mess, closely related to the PDB, but even worse. It has seen some refactoring, but just to the point where it was unavoidable to fix misbehavior or to get rid of calling deprecated GLib APIs. While the PDB cleanup has come a long way, I’m still in the middle of chopping and re-assembling the plug-in stuff:

Lots and lots of global variables have been moved to a new object, the GimpPlugInManager (app/plug-in/gimppluginmanager.c). Well they were not really global variables before, but members of the global Gimp instance, which is supposed to be the only “global” variable in the GIMP, but that doesn’t make much difference here.

Lots of functions are now methods of the GimpPlugInManager, which greatly helps finding them. Before, it was mostly unclear which function belonged to the plug-in instances themselves, and which to the infrastructure around that keeps is all together.

That’s where I am today, but there are still quite some hacks ahead before the stuff can be called “finished”:

The PlugIn struct (app/plug-in/plug-in.c) has to become an object, and this object needs some signals. Some code needs to listen to these signals, so cross-calling between unrelated scopes doesn’t happen any more. At some point people will even be able to understand how the plug-ins’ memory management is supposed to work Currently the calls to plug_in_ref() and plug_in_unref() are not really in places where one would expect them. I bet there is more uglyness that will go away as soon as I find it.

Now what are the benefits from all this work? Well, refactored code looks soooo much nicer

But seriously:

The refactored code does look nicer, is easier to read and understand, is easier to change and fix.

The PDB can check the passed arguments much better now. Thanks to GParamSpec GIMP can tell a plug-in/script developer which of the passed arguments was wrong in which way.

Every argument has a default value now. After GIMP 2.4 this will allow us to change the plug-in side of calling PDB procedures to something that has named parameters with default values. No more breaking scripts just becuase somebody added an optional argument.

(actually, optional arguments were impossible before).

Now that it’s all cleaned up, people != hardcore_longtime_developers can understand and change it.

And many other benefits that usually show up after the refactored code is in use for some time.

And now, please get GIMP from CVS and test it until it breaks. Then report the bug so the new PDB will be as solid as the old one.

While spending some time in the south of Germany, I took the opportunity to do some Night Skiing.

The location is really nice. As an extra goodie, there is a small wooden cabin at the top of the lift, where they serve some small dishes and drinks. We stayed there until the lights were turned off, and had to go down in the dark, which isn’t exactly easy after two beers

I’m very excited today My co-worker Anders Carlsson has spent the last two months with starting a port of GTK+ to the Mac OS X Cocoa framework, so GTK+ applications will eventually run natively (without needing X11) on that platform.

The port is still in its early stages and incomplete, but after these few weeks it’s already complete enough to give compiling GIMP a try.

I was trying to run GIMP on the port for about a week now, but the port was not complete enough, so I almost fell apart when I tried it again after Anders’ latest commits last night:

Wheeeeeeeeeeee! This is just amazing, especially after just two months of hacking. And Anders will continue improving it. The source will be public soon for others to help improving, and I will definitely keep GIMP running on it constantly. This will be a lot of fun!

(Disclaimer: the screenshot above is really a very early state, GIMP was just generous enough to not crash but show these three windows instead. It will be constantly improving, both look-and-feel and desktop-integration wise, so please don’t complain that GIMP on OS X should actually look a bit different ;))

It seems to become popular: Sven and Antenne already mentioned it in their blogs. Now Akkana Peck has created a small script that allows to do “Paperless Menu Prototyping” using GIMP layers.

Just enter a newline-separated list of words and the script will create an image featuring each word on a layer that can be dragged around. Add some guides for proper alignment, some separators and soon you’ll have a prototype that you can share with others, while keeping everything editable.