MyPaint and goats at LGM2012

Already covered in the news from LGM was the release of GIMP 2.8, and that GIMP 2.10 will be fully GEGLified. The goat-invasion branch which has most of that work, the result of 3 weeks of pippin and mitch on a couch hacking together, has already landed in master. This means that GIMP now has support for high bit-depth workflows for most operations. Finally.

Putting the goat in MyPaint

During LGM I started working on using GEGL in MyPaint. I have already mentioned this idea several times, so it was time to stop talking and get hacking.

As a first step in making use of GEGL I wanted to replace the current surface implementation with one based on GeglBuffer. Since GeglBuffer already provides tiling, and can store any buffer data supported by Babl this turned out to be easy. Øyvind (pippin) added the semi-quirky pixel format we currently use* in MyPaint to Babl, and I was able to get a rough working GEGL based Surface implementation the first evening.

The MyPaint brush engine working on top of GeglBuffer

* RGBA premultiplied alpha, in 16 bit unsigned integers with  2^15 being the maximum value.

The next couple of days went to moving to the GeglBufferIterator API instead of gegl_buffer_{get,set} to have zero-copy access to improve performance, and improving GEGL and GEGL-GTK so that some of the hacks in the initial implementation could be removed.

Most of the work is in the gegl branch of MyPaint. A simple test application, mypaint-gegl.py, is included, and you can read README.gegl for how to try it out. Warning: only intended for curious developers at this stage.

A lots of work remains to be done for MyPaint to be able to fully use GEGL. The progress is tracked in two bugs, one for MyPaint work and one for GEGL issues. Because one cannot combine PyGObject with PyGTK, it will likely not be possible to fully integrate GEGL in MyPaint before porting to PyGI and GTK+ 3.

Oh, in case the goat references are lost on you – check the GEGL page on wikipedia.

6 thoughts on “MyPaint and goats at LGM2012”

  1. It’ll probably be a lot easier to use the pygtkcompat module available in newer pygobject releases.

  2. Yes, that is something I will have to evaluate. It only being available in pygobject 3.2+ means it will not be in many distros yet, but maybe that is not an issue for us.

Leave a Reply

Your email address will not be published. Required fields are marked *